本文目录
Mihomo、Clash Meta、原版 Clash，先分清它们是不是同一层东西
Original Clash 通常指 Dreamacro 发起的早期 Clash 内核；Clash Meta 是在其配置思路上继续扩展的分支；Mihomo 则是 Clash Meta 后来采用的项目名称。
Clash Meta 与 Mihomo 指向同一项目的不同阶段，不是两套需要二选一的新内核。很多旧教程写“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 的合理场景通常很窄：某套离线环境已经冻结，配置只使用它已知的能力，而且升级风险高于收益。即便如此，也应记录二进制来源、版本和回退方法，不应继续把旧内核暴露为公网控制服务。
- 普通桌面用户
- 选内置 Mihomo 的持续维护客户端，从一份干净订阅开始。
- OpenWrt 用户
- 同时确认插件版本、Mihomo 核心架构和可用存储，不只升级 LuCI 页面。
- 服务端或容器部署
- 锁定明确版本，先在测试目录运行配置检查，再替换运行实例。
- 遗留原版环境
- 保持隔离与可回滚，不将新协议订阅直接推给旧核心。
迁移时先复现旧行为，再逐项启用新能力
一份配置的安全迁移顺序
保留旧配置
备份旧配置、内核版本和一组可重复访问的测试地址。
移除客户端私有项
不要把旧 GUI 的窗口、缓存或服务设置当成 Mihomo 配置复制。
先跑配置检查
处理第一条 unknown field、类型或引用错误，避免一次删掉整段。
固定相同节点
对照常用网站、内部域名和一个不读取系统代理的应用。
再开 DNS 与 TUN 扩展
一次只改变一层，观察连接记录、规则命中和退出后的网络恢复。
迁移完成的判断不是客户端显示“已连接”，而是旧环境中的关键流量在新内核里命中预期规则，局域网与内部域名仍能直连，系统代理或 TUN 关闭后网络能恢复。达成这些结果以后，再删除旧二进制和旧服务。