mihomo 与 Clash 内核对照

先分清内核、客户端与历史分支

结论先行：需要较新的协议、细粒度规则或持续维护的内核时，优先考察 mihomo；已有稳定旧配置时，应先验证兼容性，再切换实际流量。两者的差别主要是功能覆盖与维护路线，不是换一个名称就能让所有节点提速。链路质量、服务端参数和本地网络仍然决定连接表现。

Clash 是代理内核项目，负责连接转发、规则匹配与 DNS 等工作；桌面或手机客户端则提供订阅管理、托盘、系统代理和权限管理。Clash Meta 是基于 Clash 发展出的分支，后来更名为 mihomo。旧文档、配置模板与客户端设置中仍可能保留 Meta 字样，这通常反映历史命名，不代表还要额外安装第二个内核。

“原版 Clash”也需要进一步区分：历史上存在开源内核与闭源的 Clash Premium，两者功能并不完全相同。原项目已于 2023 年停止维护，不能把过去 Premium 的能力全部归到开源版名下，也不能把第三方客户端继续更新等同于原内核恢复维护。

协议支持：新增类型不等于自动兼容

mihomo 在原有代理能力上增加了多种协议和传输支持。对用户最直接的影响是：订阅中出现 VLESS、Hysteria2 或 TUIC 节点时，旧内核可能无法解析，而支持相应实现的 mihomo 可以处理。是否可用仍取决于具体版本、字段和服务端配置，不能只看节点的显示名称。

迁移节点时，核对这三组参数

• 协议凭据：服务器地址、端口、密码或 UUID 必须与服务端一致。TLS 常用端口 443 只是端口号，不是“该节点必然使用 HTTPS”的证据。
• 传输参数：WebSocket 路径、Host、gRPC 服务名等需逐项对应。YAML 能被读取，不代表握手参数正确。
• TLS 与 REALITY：核对 servername、指纹以及适用时的 reality-opts。不要用 skip-cert-verify: true 掩盖域名或证书配置错误。

如果订阅转换时已经丢掉了新协议节点，升级内核也不会让节点重新出现。应同时检查服务方提供的订阅格式、转换器输出和客户端最终生效配置。先确认节点类型确实保留，再分析握手失败，排查路径会短得多。

规则与规则集：保留顺序，区分文件格式

基础匹配逻辑没有变：在规则模式下，rules 按顺序匹配，先命中的规则决定连接交给哪个策略。DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等基础规则仍然重要，最后通常以 MATCH 接住未匹配流量。新增能力不会自动纠正错误的规则顺序。

mihomo 提供更丰富的匹配条件，例如按进程名、目标端口或逻辑组合筛选连接。不过，进程识别受操作系统、权限与流量接管方式影响。配置中存在 PROCESS-NAME，并不代表每个平台都能取得预期进程信息。

RULE-SET 不是节点订阅

• proxy-providers 用来提供节点，内容最终要能被解析为代理配置。
• rule-providers 用来提供匹配条目，再由 RULE-SET 引用并指定策略。
• behavior: domain、ipcidr 与 classical 对条目内容有不同要求，不能只改文件后缀就互换。
• mihomo 的 mrs 是规则集格式，不能直接交给原版 Clash 使用，也不能当作普通 YAML 文本编辑。

迁移自 Premium 的配置时，可能已经有 rule-providers 与 RULE-SET；迁移自原版开源内核时，则不应默认这些字段原来就可用。下面是用于验证骨架的完整小配置，故意不包含远程订阅，策略组也只有直连选项。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口选择

这份配置只验证加载、端口与规则结构，不提供代理线路。接入实际节点后，再把有效节点或节点提供者加入策略组。不要让 MATCH 排在专门规则前面，也不要让规则引用一个已经改名或不存在的策略组。

DNS 差异：关注解析路径与启动依赖

原版 Clash 已有 DNS 与 Fake-IP 能力，因此“换成 mihomo 才能使用 Fake-IP”并不准确。mihomo 的差异在于更多解析控制选项和与分流能力的组合，例如通过 nameserver-policy 为特定域名选择解析器，通过 proxy-server-nameserver 单独处理代理服务器域名的解析。

fake-ip 模式会为域名返回映射地址，随后由内核依据映射处理连接；redir-host 更接近返回真实解析结果。哪一种更合适取决于应用兼容性与网络接管方式。遇到局域网设备发现、特定游戏或企业内网异常时，应定位相应域名与访问路径，而不是直接把全部域名加入过滤列表。

三个容易混淆的 DNS 字段

TUN 与客户端：功能开关之外还有权限

系统代理通常只影响遵循系统代理设置的应用；TUN 则通过虚拟网络接口接管符合路由条件的 IP 流量。mihomo 支持 TUN，但能否正常工作仍取决于系统权限、虚拟网卡、路由规则及其他 VPN 软件。开启 TUN 不会更改服务端协议，也不会让不支持 UDP 转发的线路自动具备该能力。

1. 先验证普通代理：使用系统代理或显式 HTTP 代理测试，确认节点本身可连，再引入 TUN，避免同时排查两类问题。
2. 再检查权限：桌面客户端可能通过服务组件获取所需权限；直接运行内核时，需要按操作系统要求授予网络管理能力。
3. 最后检查路由与 DNS：auto-route、auto-detect-interface 和 DNS 接管应结合实际网络使用，尤其注意多网卡、企业 VPN 与虚拟机网络。

不要把混合代理监听端口 7890 当成 TUN 网卡端口，也不要把控制接口端口 9090 填入浏览器代理栏。控制接口供客户端管理内核，不承担普通网页代理入口的职责。若配置控制接口，优先限制在回环地址，并设置访问凭据。

旧配置迁移：按六步验证，不直接覆盖

大部分基础 YAML 结构有延续性，但“旧配置能启动”和“新配置完整生效”是两个检查点。未知字段可能被忽略，特定规则或节点也可能在后续加载阶段报错。推荐保留原配置与原客户端环境，在独立副本上逐步验证。

1. 备份配置来源：分别保存订阅原文、客户端覆写规则与当前生效配置。客户端显示的订阅文件未必等于最终交给内核的文件。
2. 记录运行环境：记录操作系统、客户端版本、mihomo -v 输出，以及是否启用系统代理和 TUN。切换前先关闭另一实例，避免端口占用。
3. 执行配置测试：在配置所在目录运行下面的命令。若规则提供者使用相对路径，注意工作目录与实际运行环境保持一致。

mihomo -v
mihomo -t -f ./config.yaml

4. 读取错误类别：YAML 缩进或类型错误先修语法；策略组不存在则检查名称；节点类型不识别则核对内核版本与订阅输出。不要看到报错就反复更新订阅覆盖现场。
5. 测试实际连接：启动内核后，以显式代理请求验证入口、节点与 TLS，再检查日志命中了哪条规则。配置测试通过不会替代实际联网验证。
6. 逐项恢复扩展：最后加入远程规则集、DNS 策略、进程规则和 TUN。每增加一项就重复测试，便于定位是哪一个改动引入异常。

curl -I --proxy http://127.0.0.1:7890 https://example.com/

该命令假设混合端口为 7890 且未设置代理认证；端口不同就相应修改。收到 HTTP 响应只能证明这一次请求完成，不能证明所有规则、UDP 应用或 TUN 都正常。还应测试一个预期直连目标和一个预期代理目标，并对照日志中的策略名称。

订阅更新后配置被还原怎么办？

如果手动编辑的是受订阅管理的文件，下次刷新很可能被服务端内容替换。应使用当前客户端支持的覆写、合并或脚本机制保存本地改动，并检查合并顺序。客户端之间的合并语法并不统一，不能把某款客户端的覆写片段直接当成 mihomo 原生字段。

选型结论：按实际需求决定迁移范围

• 需要新协议：优先选择集成合适版本 mihomo 的客户端，同时确认订阅输出保留完整节点字段。
• 需要复杂分流：核对规则提供者、进程识别、DNS 策略与目标平台支持，不只比较界面是否有“规则模式”按钮。
• 已有稳定旧环境：先用副本完成验证，再替换日常入口；迁移的目标是获得所需能力与可维护性，而不是追求名称变化。

选客户端时，可以从客户端对比核对平台与内核路线；需要进一步核对协议字段时，查看协议手册。最终判断以实际运行版本、加载日志和连接结果为准：节点可解析、规则可追踪、DNS 路径明确，才算完成一次可复现的迁移。