mihomo 内核与原版 Clash 对照:新增协议、rule-providers 与 TUN 能力差异

先区分原版开源内核、Premium 与 mihomo

结论是：mihomo 继承了 Clash 配置体系，但不能把两者视为只换了名称的同一个二进制程序。mihomo 延续了 Clash.Meta 的开发路线，增加了协议、规则与流量接管能力。迁移通常可以保留基础字段，但新配置不保证能被旧内核反向读取。

“原版 Clash”还需要分清两个对象：原版开源内核与当年的 Clash Premium。Premium 曾提供规则集与 TUN 等扩展能力。如果将它们合并成一列，再写成“Clash 不支持 rule-providers、只有 mihomo 支持 TUN”，结论就会失真。

• 客户端：负责界面、订阅管理、系统代理开关以及启动内核。客户端版本不是内核版本。
• 内核：负责读取配置、建立代理连接、解析 DNS 与执行规则。真正支持哪些字段，取决于运行中的内核。
• 订阅转换：可能按目标内核生成不同节点字段。转换器可以改变输出结构，但不能让旧内核获得新协议实现。

先在客户端的内核信息或启动日志里确认名称，再检查实际可执行文件。以下命令用于独立运行的二进制；图形客户端内置的文件可能另有名称，不要因此启动第二个内核。

mihomo -v
clash -v

协议支持对照：节点能导入，不等于能建立连接

Shadowsocks、VMess、Trojan 等是两条路线共有的常见协议。mihomo 扩展了 VLESS、Hysteria2、TUIC 等支持；具体传输组合与参数仍应按当前内核文档检查。原版历史构建之间也有差异，不能把某个旧发行版的结果推广到所有构建。

迁移时检查节点的四层参数

1. 协议类型：先看 type，例如 vless 或 hysteria2。内核不认识类型时，应更换内核或订阅输出目标。
2. 身份信息：核对密码、UUID、认证字段。把 VMess 节点直接改成 VLESS 类型并不能完成转换。
3. 传输方式：检查 WebSocket、gRPC 等传输配置是否与服务端一致，尤其是路径、Host 与服务名。
4. TLS 参数：核对服务器名称、证书验证设置与 REALITY 参数。不要用关闭证书验证代替排查。

Hysteria2 与 TUIC 使用基于 QUIC 的传输，网络必须允许相应 UDP 通信。配置测试通过，只能说明字段可被解析；如果出口网络限制 UDP，连接仍可能失败。更换内核不会自动改变网络侧限制。

rule-providers：先核对 behavior，再核对文件格式

rule-providers 用来加载规则集，不是节点订阅。节点供应器使用 proxy-providers。规则集声明完成后，还必须在 rules 中用 RULE-SET 引用，否则不会参与匹配。

从 Premium 迁移到 mihomo 时，已有的常规 YAML 规则集往往可以保留。重点检查 behavior 与文件内容是否相符：classical 放完整规则表达式，domain 放域名匹配条目，ipcidr 放 IP 网段。三种内容不能只改声明后混用。

本地 classical 规则集示例

下面的片段合并到现有主配置。Proxy 是示例策略组名称，必须替换为实际存在的组名，或在原配置中定义该组。路径相对内核工作目录，不一定相对图形客户端的安装目录。

rule-providers:
  local-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-sites.yaml

rules:
  - RULE-SET,local-sites,Proxy
  - MATCH,DIRECT

创建 rules/local-sites.yaml，内容如下。example.com 是演示域名，实际使用时换成需要分流的域名。

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

• format: yaml 的规则文件包含 payload。纯文本格式则按对应格式要求逐行写条目，不能继续套 YAML 外壳。
• mihomo 的 mrs 是二进制规则集格式，适用于 domain 与 ipcidr，不是把任意 classical 文件改扩展名就能使用。
• HTTP 类型供应器还需要实际可访问的 url。其中 interval: 86400 表示更新间隔为 86400 秒，不是连接超时。
• 规则仍自上而下匹配。宽泛规则放在前面，会让后面的精细规则没有命中机会；MATCH 通常放最后。

域名嗅探：补足域名信息，不是解密 HTTPS

IP 连接本身可能不携带可供域名规则直接匹配的目标名称。mihomo 的 sniffer 可以从 HTTP Host、TLS 握手中的服务器名称，以及可识别的 QUIC 握手信息提取域名，再辅助分流。它不等于解密 HTTPS，也不能保证所有连接都能还原域名。

以下为 mihomo 嗅探片段。建议先保留 override-destination: false，观察规则命中，再判断是否需要覆盖连接目标；它不是所有配置都必须打开的选项。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

嗅探与 Fake-IP 的边界

• Fake-IP 通过 DNS 映射保存域名与合成 IP 的对应关系；嗅探则尝试从连接内容提取域名。两者信息来源不同。
• 程序硬编码 IP、使用不可识别协议，或握手信息受加密保护时，嗅探可能拿不到有效域名。
• 需要域名规则却只看到目标 IP 时，应先检查 DNS 是否由内核处理、映射是否有效，再检查嗅探，而不是直接扩大嗅探范围。

迁移后若只有少数站点异常，可以临时关闭嗅探做对照。每次只改一个开关，并查看连接详情里的目标域名、命中规则与出口策略，避免把嗅探、DNS 与节点故障混在一起。

TUN 能力：协议栈、路由与 DNS 接管分别验证

TUN 将流量送入虚拟网络接口。它与系统 HTTP 代理不同：未遵循系统代理设置的程序，也可能通过路由进入 TUN。原版 Premium 已有 TUN，mihomo 在此方向继续扩展；不能把“支持 TUN”本身当作 mihomo 独有能力。

mihomo 的 TUN 配置可选择 system、gvisor、mixed 等栈，具体可用性取决于平台与构建。mixed 组合使用系统 TCP 栈与 gVisor UDP 栈。栈名称不是速度排名，出现问题时应在同一网络与相同节点下比较。

最小 TUN 验证片段

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

这只是合并到现有配置的 TUN 片段，还需要有效的 dns 设置。auto-route 用于自动配置路由，auto-detect-interface 用于自动识别出口接口；多个 VPN、虚拟网卡并存时，自动识别结果仍需核实。

1. 先检查权限：Windows 通常通过客户端服务或管理员权限配置虚拟接口；Linux 需要相应网络管理权限。不要把权限错误当成节点失效。
2. 再检查路由：确认虚拟接口已创建，目标流量确实进入内核。日志里完全没有连接记录时，优先查接管路径。
3. 单独检查 DNS：any:53 针对进入接管路径的常规 53 端口 DNS。浏览器自带的 DoH 通过 HTTPS 传输，不会因为这条设置就自动变成内核 DNS 查询。
4. 最后测试 UDP：节点协议、服务端、出口网络与客户端程序都可能影响 UDP。网页能打开，不能证明游戏或语音链路已正常。

旧配置迁移：分阶段加载，保留可回退路径

最稳妥的顺序是先验证配置解析，再验证普通代理，最后启用 DNS、规则集和 TUN。直接替换内核并同时打开所有新特性，失败时很难定位是哪一层改变了行为。

第一步：测试实际生效的配置

下面命令检查 config.yaml。客户端若有覆写、脚本或合并配置，应检查它最终生成的运行文件，而不是只检查订阅下载下来的原始文件。

mihomo -t -f config.yaml

遇到未知代理类型，检查订阅目标是否为 mihomo；遇到策略不存在，检查规则引用与策略组名称；遇到规则集读取失败，检查工作目录、文件路径及格式。测试通过不代表节点认证、网络连通和远程规则集更新都已成功。

第二步：用普通代理建立基线

先保持 TUN 关闭，并使用现有配置里的 mixed-port。若设为 7890，可执行下列请求。这里显式指定 HTTP 代理，便于排除系统代理开关的影响。

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

响应是否返回、连接日志是否出现、命中了哪条规则，需要一起看。这个测试只验证当前 HTTP 代理路径，不验证 UDP，也不证明所有应用都已被接管。若端口被旧进程占用，应先退出旧内核，不要随意改成多个端口同时运行。

第三步：逐项恢复增强配置

1. 恢复规则集，检查每个 RULE-SET 引用与下载状态。
2. 恢复 DNS 配置，核对 enhanced-mode、nameserver 与 nameserver-policy 的实际解析路径。
3. 按需启用嗅探，对照目标域名与命中规则。
4. 最后启用 TUN，检查接口、路由、DNS 与 UDP。

保留旧内核能读取的配置副本。回退时不仅要换回二进制，还要恢复对应规则集格式与字段；新内核生成的配置不应直接覆盖唯一的旧配置备份。

选择依据与参考资料

已有配置只使用基础协议和普通规则时，迁移重点是维护状态、平台支持与客户端集成；需要 VLESS、Hysteria2、TUIC、mrs 或精细嗅探配置时，应该选择明确采用 mihomo 且提供所需功能的客户端。客户端界面出现某个按钮，并不保证当前选中的内核能执行它。

本文按能力边界对照，不将某次发行版的表现当成永久结论。涉及平台限制、字段默认值和新增协议参数时，以实际安装版本及对应文档为准。以下资料分别用于核对项目身份、字段定义和变更记录。

• mihomo 项目仓库：项目说明、源码与问题追踪。
• mihomo 规则集配置文档：供应器类型、behavior 与文件格式。
• mihomo TUN 配置文档：栈、路由和平台相关选项。
• mihomo 域名嗅探文档：协议范围与目标覆盖设置。
• mihomo 发行记录：结合本机版本核对修复与行为变化。

需要继续核对完整配置结构，可查看本站配置进阶；首次安装和导入订阅可按教程操作。迁移验收应以“配置可解析、节点可连接、规则命中正确、接管范围符合预期”四项结果为准。