mihomo 内核与原版 Clash 差异:新增协议、规则集与配置字段对照

先分清客户端、Clash 与 mihomo

Windows 上的 Clash 客户端，通常由图形界面、后台服务与代理内核共同工作。图形界面负责导入订阅、选择策略组、设置系统代理；内核负责协议连接、DNS 处理和规则匹配。同一个客户端界面，可能在不同版本中使用不同内核。因此，界面能导入 YAML，不代表内核能运行其中所有字段。

本文把原项目的开源 Clash 与 Clash Premium 分开讨论。Premium 是原项目提供过的闭源增强内核，不等于开源版 Clash；mihomo 则来自 Clash Meta 项目，继续扩展协议和配置能力。“Clash 格式”只是常用说法，不能作为跨内核完全兼容的保证。

新增协议：节点能显示，不等于能连接

mihomo 的一个直接差异是协议覆盖更广。包含 VLESS、Hysteria2 或 TUIC 的订阅，不能直接交给原版 Clash 或 Premium 运行。不同内核对同名协议的选项支持也可能不同，例如传输方式、TLS 指纹和 UDP 处理选项，需要按具体版本核对。

Windows 中如何排查“导入成功但节点不可用”

1. 在订阅或节点详情中确认 type，不要只看节点显示名称。名称中的“高速”“专线”不说明协议类型。
2. 查看日志是否出现不支持的代理类型、未知加密或缺少字段。若配置阶段已报错，先解决内核兼容问题，不必反复测速。
3. 对于 Hysteria2、TUIC，确认当前网络允许对应 UDP 通信。网页走 HTTP 代理成功，不能证明 UDP 通路也正常。
4. 如果客户端可以选择内核，选用其支持的 mihomo 内核并重启内核进程，再核对启动日志。不要只改配置文件名。

换用 mihomo 不会自动补齐错误的服务器参数，也不会把普通订阅转换成另一种协议。服务端没有启用相应协议时，仅修改客户端的 type 会导致连接失败。

rule-providers：Premium 已有，mihomo 扩展格式

rule-providers 不是 mihomo 独有的概念。Clash Premium 已经支持规则提供器；迁移时真正需要对照的是规则行为、文件格式与引用顺序。mihomo 还支持适用于大规模域名、IP 规则的 MRS 二进制格式，但这类文件不能反过来交给旧内核使用。

先用本地规则集验证引用关系

下面是主配置中的片段，不是完整订阅。它使用内置策略 DIRECT 和 REJECT，便于单独检查规则，不依赖某个节点组名称。规则集文件应放在内核可访问的配置目录中；相对路径按内核的工作目录解析，而不一定按手动打开的 YAML 所在目录解析。

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

rules:
  - RULE-SET,local-direct,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

对应的 rules/local-direct.yaml 内容如下。classical 规则集中的条目只写匹配条件，不附加 DIRECT；最终动作由主配置里的 RULE-SET 指定。

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

• behavior: domain：放域名规则集内容，不要混入完整的 DOMAIN-SUFFIX,域名 规则行。
• behavior: ipcidr：放 IP 网段，适合按目标地址匹配。
• behavior: classical：放带规则类型的经典规则，适合混合域名、IP 等条件。
• format: mrs：用于匹配的 MRS 文件，支持 domain 和 ipcidr 行为，不用于 classical。改扩展名不会完成格式转换。

命中顺序比规则集数量更重要

常规规则按顺序匹配，先匹配到的规则决定去向。如果 MATCH 写在规则集引用前面，后续规则就没有机会处理连接。将远程规则集接入实际订阅后，还要确认动作引用的策略组确实存在；Proxy、PROXY 与中文组名不能随意互换。

Windows 客户端里，应通过配置编辑、扩展配置或覆写功能加入字段，再在配置检查和日志中确认提供器加载成功。直接修改订阅下载生成的文件，可能在下次更新时被替换。完整规则写法可查阅 YAML 手册的规则语法。

sniffer 嗅探：补充域名线索，不是解密 HTTPS

当应用直接连接 IP，或者域名到 IP 的映射没有进入内核 DNS 时，域名规则可能缺少匹配依据。mihomo 的 sniffer 可以尝试从 HTTP Host、TLS 握手中的服务器名称等信息取得域名，也支持对 QUIC 流量进行相应识别。这是它与原版 Clash、Premium 的重要配置差异之一。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  skip-domain:
    - "+.lan"

这里的 80、443、8443 是尝试嗅探的目标端口，不是新增的本地监听端口。示例将 override-destination 设为 false，用于先观察域名识别与规则匹配，避免一开始就改变连接目标的处理方式。

启用后的三个检查点

1. 打开客户端的配置编辑或覆写入口，在顶层加入 sniffer，不要把它缩进到 dns 或某个节点内部。
2. 重新加载后，新建一次访问，再看「连接」或日志中的目标域名与命中规则。已有长连接不会因为规则修改而自动重新建立。
3. 若特定内网服务异常，先停用嗅探复测，再按实际域名添加跳过项。不要一次开启多个高级开关，否则难以判断是哪项改变了行为。

DNS 字段：保留基础配置，逐步加入分流策略

原版 Clash 已有 DNS 模块和 fake-ip 等能力，所以“使用 fake-ip”并不等于“正在使用 mihomo”。mihomo 在 DNS 路由与策略方面增加了更多字段，例如 proxy-server-nameserver、direct-nameserver 和 respect-rules。这些字段不是每个场景都必须开启。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

这是用于说明字段关系的基础片段。127.0.0.1:1053 只监听本机；198.18.0.1/16 用于示例中的 fake-ip 分配，不是上游 DNS 地址。223.5.5.5 是明文 DNS 示例，不代表适合所有网络，也不代表 DNS 流量已经加密。

Windows 的系统代理主要影响遵循系统设置的应用，不会把全部系统 DNS 请求自动送到 1053。如果只是写了 dns.listen，但没有让查询进入该监听端口，配置虽然存在，也可能没有处理实际请求。应用自带的加密 DNS 还可能通过自己的网络连接访问解析服务，需要另行检查。

建议先保持 respect-rules 的默认行为，验证普通访问和节点域名解析；确实需要 DNS 上游分流时再加入该字段，并在规则里明确处理上游连接。更多字段可对照 DNS 配置说明，不要把不同教程里的整段配置直接叠加。

TUN 与系统代理：流量入口需要单独启用

mihomo 支持 TUN，但 TUN 并非它相对 Premium 才新增的功能。两者的配置字段与平台实现不能逐字照搬。Windows 上，系统代理适合浏览器等遵循代理设置的应用；TUN 则通过虚拟网卡和路由接入更多 IP 流量，通常需要客户端服务或管理员权限。

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

以上仅为 TUN 片段，需要配合已启用的内核 DNS 使用。any:53 用于接入 TUN 的传统 DNS 请求处理，不会自动接管 DoH、DoT 等其他端口上的加密查询。auto-detect-interface 也不是多网卡环境的万能修复项；同时使用企业 VPN、虚拟机网卡时，要检查实际出口与路由。

Windows 客户端中的启用顺序

1. 先在普通代理模式下验证节点与规则能工作，再考虑 TUN。基础连接失败时，开启虚拟网卡通常只会增加排查变量。
2. 在客户端「设置」中找到服务模式相关入口，按客户端提示安装或启用服务。若提示需要权限，应确认并完成授权。
3. 开启界面中的「TUN 模式」或「虚拟网卡」开关，重新查看日志。客户端可能自行生成 tun 字段，应以合并后的配置为准。
4. 测试浏览器与一个不使用系统代理的应用，并在连接列表确认流量确实进入内核。异常时关闭 TUN 复测，保留日志后再检查网卡与路由。

不同客户端的菜单不统一，因此不要把某个界面的开关位置当作内核规范。可用功能取决于客户端如何管理服务、内核版本以及最终配置，而不只是 YAML 里是否出现 enable: true。

迁移核对：检查最终配置，再验证真实流量

从 Premium 或旧版 Clash 迁移到 mihomo，建议保留原配置副本，按“基础代理 → 规则集 → DNS → 嗅探 → TUN”的顺序启用。Premium 的 script 功能不能直接当成 mihomo 的同名能力；客户端的 JavaScript 覆写脚本又属于另一层，它负责生成或修改配置，不是内核规则脚本。

用配置检查区分语法问题与连接问题

将待测试文件保存为 config.yaml，在独立的测试目录运行以下命令。客户端环境应检查其合并后的运行配置；订阅源文件通过检查，不代表覆写后的文件也一定通过。

.\mihomo.exe -t -f .\config.yaml

配置检查用于发现解析错误、缺失引用和部分非法字段，不能证明节点可达，也不能保证每个无效或不受支持的选项都会报错。若检查通过但功能没有生效，应继续看启动日志、最终配置以及实际连接命中结果。

用固定端口验证代理链路

假设实际运行配置使用 mixed-port: 7890，并且允许本机连接，可以在 Windows PowerShell 中执行下面的命令。这里明确使用 curl.exe，避免旧版 PowerShell 中同名别名造成参数差异。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

• TcpTestSucceeded: True 只说明本机端口可连接，不说明远端节点已经正常工作。
• 收到目标站点 HTTP 响应后，再查看连接记录中的规则与出口。示例站点只是测试目标，不用于测速或判断全部网站可达性。
• 如果客户端使用的端口不是 7890，先从设置或最终配置读取实际值，再修改命令；不要为了套用命令随意改端口。
• HTTP 代理测试不覆盖 TUN、应用自带 DNS 或 UDP 通信，这些需要分别建立新连接验证。