mihomo 内核比原版 Clash 强在哪:协议支持、规则集与 TUN 差异对照

先分清内核与客户端

Clash、mihomo 与 FlClash 处在不同层级。内核负责读取 YAML 配置、建立代理连接、匹配规则、处理 DNS 与转发流量；客户端负责订阅管理、配置编辑、系统代理开关、日志展示和平台权限申请。FlClash 是图形客户端，mihomo 是它可以使用的代理内核。比较“原版 Clash 与 mihomo”时，真正对照的是两套内核能力，而不是窗口布局或按钮数量。

通常所说的原版 Clash，是 Dreamacro 发布的开源 Clash。其公开版本停留在 v1.18.0，常见基础能力包括 HTTP、SOCKS5 与 mixed 入站，规则模式、策略组、DNS 处理，以及 Shadowsocks、VMess、Trojan 等代理类型。Clash Meta 从原版代码体系继续扩展，后来更名为 mihomo。很多配置字段仍然兼容，因此旧订阅通常可以直接载入，但兼容不等于两者功能完全相同。

一组可直接观察的差异

能力	原版 Clash	mihomo	日常影响
基础规则与策略组	支持	兼容并持续扩展	旧配置迁移成本较低
新型出站协议	范围固定	支持 Hysteria2、TUIC、VLESS、WireGuard 等	订阅包含新节点时无需另换内核
规则集	具备基础 rule-providers 体系	格式、匹配行为与更新能力更完整	大型规则可拆分维护
TUN	不同发行形态能力不一	持续维护自动路由、严格路由与多种协议栈	可接管不读取系统代理的程序
流量嗅探	能力有限	独立 sniffer 配置与覆盖策略	透明代理下能恢复域名信息

协议支持：差别首先出现在节点类型

原版 Clash 的常见出站类型已经能覆盖传统订阅：Shadowsocks、VMess、Trojan、HTTP、SOCKS5 与 Snell 等。问题在于代理协议仍在演进。服务端如果提供 Hysteria2、TUIC、VLESS Reality、ShadowTLS 或 WireGuard 节点，旧内核可能直接提示代理类型不受支持，也可能在解析订阅后忽略对应节点。

mihomo 对这些类型提供原生配置入口，并让它们进入统一的策略组、健康检查和规则分流体系。例如，一个 url-test 策略组可以同时容纳传统 Trojan 节点和 Hysteria2 节点，再按探测延迟自动选择。对用户而言，增强点不是协议名称更多，而是订阅中的节点可以被同一套规则调用。

协议增加不代表必须全部启用

Hysteria2：基于 QUIC，常使用 UDP，适合服务端与网络环境均允许稳定 UDP 的场景。
TUIC：同样依赖 QUIC 与 UDP，参数中的 UUID、密码、拥塞控制设置必须与服务端一致。
VLESS：可配合 TLS、Reality 与不同传输方式使用，不能仅凭节点名称判断传输结构。
WireGuard：以隧道接口模型工作，需要正确填写私钥、公钥、地址和允许路由范围。
ShadowTLS：用于特定链式结构，实际配置通常还会引用另一个拨号代理。

选择节点时仍应看服务端部署质量、链路丢包和本地网络。一次延迟测试只能反映探测 URL 在当时的往返时间。例如，同一网络中 TCP 节点探测为 82 ms，QUIC 节点探测为 61 ms，不等于后者在持续下载时一定更快；若运营商对 UDP 限速，QUIC 节点可能在数分钟后出现明显抖动。

rule-providers：大型规则从配置正文中拆出去

rule-providers 的核心用途是把规则存入独立文件，再由主配置通过 RULE-SET 引用。这个概念并非 mihomo 凭空增加，原版 Clash 的后期配置体系已经能见到规则提供者；mihomo 的优势在于持续完善格式支持、匹配类型、更新流程与相关行为，并能配合更丰富的规则语法使用。

一份只有几十条规则的配置，可以把域名直接写在 rules 下。规则达到数万条后，继续内嵌会让主文件难以阅读，也会让订阅覆写和版本管理变得复杂。拆分后，主配置只保留规则集地址、更新周期和目标策略，规则内容由独立文件维护。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/private-domain.yaml
    path: ./ruleset/private-domain.yaml
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://example.com/rules/private-ip.yaml
    path: ./ruleset/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,节点选择

behavior 决定文件里能写什么

domain：用于域名类条目，适合域名后缀、完整域名等集合。
ipcidr：用于 IPv4、IPv6 网段。若当前匹配不需要触发 DNS，可在引用规则后添加 no-resolve。
classical：每一项可以带完整规则类型，例如 DOMAIN-SUFFIX、PROCESS-NAME 或 IP-CIDR。

interval: 86400 表示每 86400 秒检查一次远程规则，也就是 24 小时。它不是“每次请求都下载”。首次获取成功后，内核会使用本地缓存；远程服务器暂时不可达时，已有文件通常仍可继续参与匹配。需要注意，规则地址本身也必须能被当前网络访问，否则首次启动可能没有可用缓存。

mihomo 还支持面向规则集合的二进制 mrs 格式。它适合体积较大的域名或 IP 规则集，目标是减少解析开销和存储占用。mrs 不是普通文本，不能直接用编辑器逐行修改；需要人工维护的私有规则，继续使用 YAML 或文本格式更直观。

规则顺序仍然高于规则数量

Clash 规则采用自上而下、首次命中即停止的逻辑。即使规则集更新成功，如果把宽泛的代理规则放在直连规则之前，后面的直连项仍不会执行。常见顺序是私有域名、局域网与保留地址在前，业务规则集居中，GEOIP 或其他区域判断靠后，最后用 MATCH 收口。

TUN 模式：从系统代理扩大到全局流量接管

系统代理通常只影响主动读取操作系统代理设置的应用。浏览器大多支持，但游戏、命令行工具、部分商店客户端、虚拟机程序和直接发起 UDP 通信的软件可能绕过它。TUN 模式会建立虚拟网络接口，把符合路由条件的 IP 流量送入内核，因此覆盖范围更广。

原版 Clash 的不同版本与发行形态曾提供过 TUN 能力，但配置、平台适配和维护状态并不统一。mihomo 对 TUN 的自动路由、DNS 劫持、多种网络协议栈、接口选择和严格路由持续扩展，这也是现代图形客户端普遍采用 mihomo 的重要原因。

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

这几个字段分别控制什么

stack: mixed：使用混合协议栈处理连接，通常可作为桌面端的起点。具体可选值应以当前内核版本为准。
auto-route: true：自动写入需要的路由，让目标流量进入 TUN 接口。
auto-detect-interface: true：自动识别当前默认出口，减少 Wi-Fi 与有线网络切换后的手工调整。
strict-route: true：加强路由约束，减少部分流量绕过 TUN 的可能；某些虚拟化或局域网环境需要额外测试。
dns-hijack：接管指定端口的 DNS 请求。传统 DNS 通常使用 UDP 或 TCP 53 端口。

在 FlClash 中，通常应先导入配置并确认普通系统代理可用，再进入「设置」→「网络设置」启用 TUN 模式。Android 与桌面系统会要求创建 VPN 或虚拟网络接口；授权后再检查日志中的 TUN 初始化结果。若客户端版本的菜单文字略有调整，可在「设置」中查找 TUN、VPN 服务或网络接口相关项目。

TUN 常见冲突点

其他 VPN 同时运行：两个程序都尝试接管默认路由时，可能出现断网或路由反复切换。
局域网访问异常：打印机、NAS 或开发设备所在网段需要加入直连规则，常见私网包括 192.168.0.0/16、10.0.0.0/8 与 172.16.0.0/12。
虚拟机与容器网络：Docker、WSL、Hyper-V 等会创建虚拟网卡，自动接口识别不正确时需要检查出口选择和排除路由。
DNS 被重复接管：系统安全软件、加密 DNS 工具与 mihomo 同时监听或重定向 DNS，可能造成查询超时。

嗅探能力：透明代理仍能找回域名

规则引擎更适合按域名判断流量，但 TUN 首先看到的往往只是目标 IP。例如某个应用已经自行完成 DNS 查询，随后直接连接 203.0.113.10:443，内核若只拿到 IP，就无法直接使用 DOMAIN-SUFFIX 规则。嗅探器会分析连接早期数据，从 TLS 的服务器名称、HTTP Host 或 QUIC 信息中提取目标域名，再用于规则匹配。

sniffer:
  enable: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip 允许对目标表现为纯 IP 的连接尝试识别域名；override-destination 决定是否用嗅探结果覆盖原目标信息。端口范围应按实际业务设置，不宜为了“覆盖全部”而对所有端口启用每一种解析器。非 HTTP、TLS 或 QUIC 的私有协议无法凭这些解析器获得有效域名。

嗅探不是 DNS 的替代品

嗅探发生在连接建立阶段，DNS 决定域名如何解析，两者解决的问题不同。稳定配置通常仍需要合理设置 nameserver、fallback、fake-ip 或 redir-host 等 DNS 字段。若使用 Fake IP，内核会把域名映射到保留地址池，再在连接阶段还原域名；嗅探则可补足绕过内核 DNS、直接连接 IP 的流量。

少数应用会使用证书固定、加密客户端问候或自定义 QUIC 行为，嗅探未必能得到可用名称。遇到连接被错误覆盖时，可以先查看日志中的原始目标与嗅探目标，再通过跳过域名或跳过源地址规则排除特定业务，而不是直接关闭全部嗅探。

DNS、规则与 TUN 必须作为一套配置检查

mihomo 的增强能力彼此关联。只打开 TUN，不处理 DNS，可能出现规则拿不到域名；只启用嗅探，不设置正确的规则顺序，恢复出的域名仍会命中错误策略；规则集配置正确，但下载地址被当前网络阻断，首次启动时规则文件又无法落盘。排查时应按“入站接管 → DNS → 嗅探 → 规则匹配 → 策略组 → 出站连接”的顺序查看日志。

一套可重复的检查流程

在普通系统代理模式下确认至少一个基础节点可以建立 TCP 连接。
检查 mixed 入站端口是否被占用，常见值是 7890，不要让两个客户端监听同一端口。
确认 DNS 日志能返回结果，并观察返回的是实际 IP 还是 Fake IP 地址。
启用 TUN 后关闭系统代理，测试不读取系统代理的应用是否进入内核日志。
查看连接记录中的 Host、目标 IP、命中规则和最终策略组，确认嗅探结果没有误覆盖。
手动更新规则提供者，确认 HTTP 状态、保存路径和更新时间；再等待一个完整的 interval 周期验证自动更新。
分别测试 TCP 与 UDP。网页可打开只说明 TCP 路径基本正常，不能证明 QUIC、游戏语音或 DNS 的 UDP 路径正常。

哪些用户能直接感受到 mihomo 的提升

只使用浏览器、基础 Shadowsocks 节点和几条域名规则的用户，切换内核后未必立刻看到速度变化。mihomo 的价值更偏向“覆盖能力与配置上限”：订阅出现新协议时可以解析，应用绕过系统代理时可由 TUN 接管，透明流量缺少域名时可由嗅探补足，大型规则则可通过规则提供者独立更新。

订阅包含 Hysteria2、TUIC 或 VLESS：协议兼容是直接需求。
需要代理游戏、终端或商店客户端：TUN 比单独设置 HTTP 系统代理覆盖更完整。
维护大量分流规则：rule-providers 能把主配置与规则数据分离。
使用 Fake IP 和透明代理：DNS、嗅探与域名规则联动更重要。
频繁切换 Wi-Fi、有线与热点：自动接口识别与自动路由可减少手工调整。

旧配置迁移到 mihomo 时，不必立即打开所有增强项。更稳妥的顺序是先验证节点和策略组，再验证规则，随后调整 DNS，最后启用 TUN 与嗅探。这样出现异常时，能快速定位是代理协议、解析链路、规则顺序还是系统路由导致。

结论可以压缩为四点：原版 Clash 奠定了配置语法和规则代理模型；mihomo 延续其兼容基础，并持续加入新协议；规则提供者更适合维护大型、可更新的规则数据；TUN 与嗅探则让分流从“支持系统代理的应用”扩展到更完整的设备流量。实际配置应围绕需要启用功能，而不是机械堆叠字段。