本文目录
阅读教程时遇到不同项目名，最容易误把界面程序、代理内核和旧名称当成几个互相替代的工具。判断配置是否适合当前设备，真正要看实际运行的内核及版本。名称关系可以帮你读懂旧文档，兼容性还要靠配置检查和真实连接确认。
Clash Meta 与 Mihomo 是同一项目的不同名称
Mihomo 是 Clash Meta 后来采用的项目名称。Original Clash 通常指 Dreamacro 发起的早期 Clash 内核；旧教程中的 Meta 与当前日志中的 Mihomo，不代表两套需要二选一的内核。
更容易混淆的是客户端名称。Clash Verge Rev、FlClash 和 Clash Party 是图形客户端，它们负责订阅、系统代理和界面，里面实际运行的内核才可能是 Mihomo。文件名带 Clash，不足以证明它使用的是原版 Clash。
名称对应的层级
| 名称 | 通常指什么 | 现在看它有什么用 |
|---|---|---|
| Original Clash | 最初的 Clash 内核与基础配置模型 | 理解历史配置和旧客户端行为 |
| Clash Meta | 在原有模型上扩展的后续内核名称 | 阅读旧文档、旧日志和旧订阅说明 |
| Mihomo | Clash Meta 当前使用的项目名称 | 新部署、当前字段和维护中的内核 |
| Clash 图形客户端 | 管理内核的桌面或移动应用 | 看界面、平台支持和实际内置内核版本 |
查看实际运行的客户端与内核版本
同一份订阅在两台电脑上表现不同，先核对实际加载的配置、内核和版本。可在客户端的“设置 → 关于”“内核”或“运行日志”中记录完整名称与版本；命令行部署则查看当前运行的二进制，不用路径中另一份同名程序的结果代替。
mihomo -v
# 如果机器上运行的是旧名称的二进制，也应先看它自己的版本
clash -v记录时不要只写“最新版”
- 客户端名称与版本
- 内核显示为 Mihomo、Clash Meta 还是 Clash
- 内核具体版本号
- 操作系统和 CPU 架构
- 发生错误时实际加载的配置文件
配置格式相似，也不能直接在不同内核间来回使用
Mihomo 延续了 proxies、proxy-groups 和 rules 等核心结构，所以基础配置看起来很熟悉。但它后来增加或扩展了协议、DNS、TUN、规则集、嗅探和运行时字段。
旧内核遇到自己不认识的内容，可能报 unknown field、unsupported proxy type，也可能直接忽略某些字段，留下更难发现的行为差异。
旧配置迁到新内核也可能需要调整。若旧配置使用的行为、脚本能力或客户端生成字段已经变化，在 Mihomo 中就要重新验证。兼容不能只看“YAML 能打开”，还要配置检查通过、策略组引用完整，规则命中与 DNS 结果都符合预期。
同一份订阅最容易出现差异的地方
| 部分 | 原版 Clash 环境 | Mihomo 环境 | 迁移时怎么做 |
|---|---|---|---|
| 节点协议与传输 | 取决于旧核心及其版本，只认识当时支持的字段 | 持续增加和维护更多协议与传输选项 | 出现 unsupported proxy type 时核对内核，不删除节点字段硬凑 |
| DNS | 不同开源/Premium 版本的能力与字段并不完全一样 | 当前文档包含完整的 DNS、Fake-IP 和 nameserver 选项 | 先沿用最小 DNS，再逐项迁移 Fake-IP 过滤和上游 |
| TUN | 是否可用取决于旧版分支、版本和客户端集成 | 当前 Mihomo 与主流客户端普遍提供 TUN | 先用系统代理验证，再单独开启 TUN 和服务权限 |
| 规则与 Provider | 旧核心只接受它认识的规则类型和结构 | 支持当前文档中的规则、规则集及扩展字段 | 检查 rule-provider behavior、策略组名称和最终合并结果 |
| 客户端附加字段 | 可能由旧 GUI 的 Mixin、Parsers 或脚本生成 | 由新客户端的 Merge、Script 或覆写生成 | 按原用途重建，不整段复制客户端私有配置 |
unknown field
常见原因：当前内核不认识该字段，或字段被放错层级
处理方法：以实际内核版本的官方文档核对，不靠删除冒号试错。
unsupported proxy type
常见原因：协议或传输能力超出当前内核支持
处理方法：升级到服务方要求的维护中内核，或改用兼容节点。
proxy/group not found
常见原因：策略组、规则或覆写引用的名称不存在
处理方法：检查最终合并配置，而不只看原始订阅。
能加载但规则表现不同
常见原因：DNS、规则顺序或客户端覆写改变了运行结果
处理方法：用连接记录对照同一域名的命中规则和出口。
新装环境优先选维护中的 Mihomo，旧内核只留给明确的遗留需求
如果现在重新安装桌面客户端、路由器插件或服务器服务，优先选择明确使用 Mihomo、仍有官方发布和问题跟踪的项目。这样做主要是为了当前系统兼容、安全修复和文档一致，而不是因为名称更新就自动更快。
保留 Original Clash 的合理场景通常很窄：某套离线环境已经冻结，配置只使用它已知的能力，而且升级风险高于收益。即便如此，也应记录二进制来源、版本和回退方法，不应继续把旧内核暴露为公网控制服务。
- OpenWrt 用户
- 同时确认插件版本、Mihomo 核心架构和可用存储，不只升级 LuCI 页面。
- 服务端或容器部署
- 锁定明确版本，先在测试目录运行配置检查，再替换运行实例。
- 遗留原版环境
- 保持隔离与可回滚，不将新协议订阅直接推给旧核心。
把旧配置迁到 Mihomo：备份、配置检查与实际连接测试
一份配置的安全迁移顺序
保留旧配置
备份旧配置、内核版本和一组可重复访问的测试地址。
移除客户端私有项
不要把旧 GUI 的窗口、缓存或服务设置当成 Mihomo 配置复制。
先跑配置检查
用实际选定的 Mihomo 二进制，在独立测试目录检查候选配置；命令示例见下方。处理实际出现的首条解析、类型或引用错误，避免一次删掉整段。
固定相同节点
先对照常用网站与内部域名；不读取系统代理的应用留到下一步开启 TUN 后再测试。
再开 DNS 与 TUN 扩展
一次只改变一层，观察连接记录、规则命中和退出后的网络恢复。
以下命令按 Mihomo v1.19.32 的参数示例写成。把二进制和两个绝对路径换成实际位置，测试目录要有候选配置需要的可信 Provider 与数据文件副本，不能指向正在运行的目录。
-t 检查后退出，-d 指定工作目录，-f 指定配置。初始化可能写入测试目录或取得所需资源，不等于完全只读；成功输出只证明配置检查通过，连接、规则和退出恢复仍须另外验证。检查通过也不证明未知或旧客户端私有字段受支持，仍须对照该版本文档。
mihomo -t -d '/absolute/path/to/test-data' -f '/absolute/path/to/candidate.yaml'迁移完成的判断不是客户端显示“已连接”，而是旧环境中的关键流量在新内核里命中预期规则，局域网与内部域名仍能直连，系统代理或 TUN 关闭后网络能恢复。达成这些结果以后，再删除旧二进制和旧服务。