mihomo 内核与原版 Clash 核心差异全览:新增协议与规则能力解析

内核是什么,和客户端界面是什么关系

Clash 生态里"客户端"和"内核"是两个独立的部分。内核(core)是一个不带图形界面的可执行程序,负责解析配置文件、建立代理连接、执行分流规则、处理 DNS 查询,并通过一个本地 HTTP API(通常监听 127.0.0.1:9090)对外暴露状态和控制接口。客户端(Clash Plus、Clash Verge Rev、FlClash 等)则是包裹在内核外面的图形界面,负责订阅管理、节点展示、开关切换,底层的所有代理工作都是转发给内核完成的。

这个分层结构决定了一个关键事实:客户端换皮容易,内核换代不易。用户平时感知到的"界面好不好用"是客户端层面的差异,而"支不支持某个协议""某条规则写不写得出来"则完全取决于内核版本。这也是为什么在讨论 Clash 生态时,把内核单独拎出来分析是有必要的。

原版 Clash 内核的现状:已停止更新与归档

最早由社区维护的原版 Clash 内核(仓库名通常写作 Clash 或 Clash Premium)已经停止更新,仓库处于归档(archived)状态,不再接受新的 issue 和 PR,也不会再发布新版本。原因与 Clash for Windows 图形客户端下架的背景相似,均涉及原作者账号与相关仓库被下线处理。

原版内核在停更时的能力大致停留在以下水平:

• 协议支持:Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等主流协议,不含 Hysteria、TUIC 等后期出现的协议。
• 规则类型:DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH 等基础规则,没有 rule-providers 远程规则集机制,也没有进程级规则。
• DNS 能力:提供基础的 DNS 转发和污染防护,不含 Fake-IP 精细化管理和嗅探(sniffer)能力。
• TUN 模式:早期版本不支持或支持非常有限,跨平台一致性差。

对普通用户而言,原版内核依然能运行现存的旧配置文件、依然能连接常见节点,不会突然失效。但它不会再获得新特性,遇到的任何 bug 也不会有官方修复,长期使用存在功能滞后的风险。

mihomo(Clash Meta)是什么,与原版是什么关系

mihomo 的前身是社区分支项目 Clash Meta,在原版内核发展停滞后,由另一批贡献者基于原版代码继续开发,持续合入新协议、新规则类型和性能优化,后来正式独立命名为 mihomo。目前市面上几乎所有仍在活跃更新的桌面与移动客户端——包括 Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android 的后续分支——底层跑的都是 mihomo 内核,而不是原版内核。

需要澄清一个容易混淆的地方:mihomo 不是另起炉灶的全新项目,它的配置文件语法与原版内核高度兼容,绝大多数原版配置字段(port、mode、proxies、proxy-groups、rules 等)可以原样保留,mihomo 在此基础上做的是"扩展"而非"替换"。这也是为什么迁移旧配置文件到 mihomo 内核的客户端时,大多数场景不需要重写配置,只需要补充新增字段即可享受到新能力。

协议支持差异:哪些协议是原版内核跑不了的

协议支持是两者最直观的差异。mihomo 在原版协议基础上新增支持了多种后期出现的传输协议,这些协议在延迟和抗封锁能力上各有侧重:

如果订阅节点列表里出现了 Hysteria2 或 TUIC 类型节点,在原版内核上会直接解析失败或被跳过,表现为"节点列表里少了几个"或客户端报配置错误。这类问题的根本原因往往不是配置文件写错了,而是内核版本太旧,换成基于 mihomo 的客户端即可解决。

规则能力差异:rule-providers 与更细粒度的匹配

规则系统是 mihomo 相对原版内核提升最大的部分之一。原版内核的 rules 字段只能逐条罗列固定规则,规则数量一多,配置文件会变得极其臃肿且难以维护。mihomo 引入了 rule-providers 机制,允许把规则集抽取成独立的远程文件,主配置里只需引用:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

规则集文件会按 interval 指定的周期自动刷新,规则维护者更新分类规则后,用户端会在后台静默同步,不需要手动替换整份配置文件。这也是目前主流"一键订阅"配置方案能够长期保持规则准确性的技术基础。

除此之外,mihomo 还新增了原版没有的规则类型:

• PROCESS-NAME / PROCESS-PATH:按发起连接的进程名或路径分流,可以做到"只让某个应用走代理,其余应用直连"。
• IP-CIDR6:IPv6 地址段匹配,弥补原版对 IPv6 支持的缺口。
• SCRIPT(部分实现):允许用简单脚本逻辑判断分流条件,适合复杂场景。
• SUB-RULE:子规则集嵌套引用,便于把庞大规则表拆分成可复用的模块。

对绝大多数家庭用户来说,进程级规则的意义在于可以精确控制"哪个软件走代理",避免规则粒度只能到域名/IP 层面导致的误判问题。

DNS 与 Fake-IP 能力差异

DNS 处理是另一个体感差异明显的模块。原版内核的 DNS 模块功能较为基础,主要解决"DNS 污染导致解析到错误 IP"的问题。mihomo 在此基础上完善了 Fake-IP 机制与嗅探能力:

• Fake-IP 模式:为域名分配一个虚拟 IP 段内的地址,应用发起连接时先拿到假 IP,真正建连阶段再由内核还原出原始域名进行分流判断,减少了传统 DNS 模式下"先查询解析,再判断分流"的往返延迟,对基于域名分流的规则尤其友好。
• 嗅探(sniffer):对于配置了 IP-CIDR 或 GEOIP 规则却缺少对应域名信息的连接,mihomo 可以从 TLS SNI 或 HTTP Host 字段里嗅探出目标域名,再套用域名类规则,弥补部分场景下 Fake-IP 与规则不匹配的问题。
• DNS 分流:可以为不同网络环境(国内/国外)配置不同的上游 DNS 服务器,并结合 fallback-filter 判断结果是否可信,原版内核在这方面的可配置项明显更少。

API 能力与客户端联动差异

内核对外暴露的 HTTP API 决定了客户端能实现哪些实时交互功能。原版内核的 API 覆盖节点列表、连接状态、日志推送等基础能力。mihomo 在此基础上扩展了更多可查询与可控制的接口,包括:

• 按代理组查询延迟测速结果,支持并发测速多个策略组。
• 连接维度的详细流量统计,区分上传/下载字节数与实时速率。
• 规则命中追踪,可以查到某条连接具体命中了哪一条规则、走了哪个代理。
• 配置热重载接口,客户端切换订阅或修改规则后可以不重启内核直接生效。

这也解释了为什么现在的客户端能做到"连接详情页实时刷新每条流量的规则命中情况",这类界面能力完全依赖底层 API 是否提供对应数据,原版内核的 API 覆盖面不足以支撑这类界面。

旧配置文件迁移到 mihomo 是否需要重写

由于 mihomo 在字段层面对原版保持了良好的向后兼容,大多数旧配置文件可以直接导入运行,常见的迁移动作只是"补充"而非"重写":

1. 直接导入测试

   把订阅链接或本地配置文件原样加入基于 mihomo 的客户端,先确认能否正常连接与分流,大部分基础字段无需改动。

2. 检查协议解析报错

   如果日志里出现某个节点解析失败,通常是协议类型太新或太旧导致的字段不匹配,可以先跳过该节点排查其余部分是否正常。

3. 补充新增字段

   按需加入 rule-providers、sniffer、tun 等 mihomo 特有字段,充分利用新内核能力,而不是止步于"能跑起来"的最低标准。

4. 核对策略组测速逻辑

   mihomo 的 url-test 和 fallback 策略组在超时判定和健康检查上做了优化,建议核对 interval 和 tolerance 参数是否仍符合预期。

唯一需要重写而非直接迁移的场景,是配置文件里用到了原版从未支持、而是第三方魔改分支自定义的私有字段,这类情况较为少见,遇到时以 mihomo 官方文档字段说明为准逐条核对即可。

该如何选择:内核层面的实际建议

把上述差异归纳成一句话:原版内核已经归档,功能停留在停更前的水平,不会再有新协议和新规则能力;mihomo 是当前活跃维护、协议与规则能力持续扩展的内核,且对原版配置保持兼容。因此从内核选择角度,没有必要为了"用回原版"而放弃新特性,直接选择底层基于 mihomo 的客户端是更省心的路径。

具体判断上,可以按以下几点快速核对当前使用的客户端内核情况:

• 查看客户端"关于"或"版本信息"页面,通常会标注内核名称与版本号,标注 mihomo 或 Meta 字样即为新内核。
• 尝试添加 Hysteria2 或 TUIC 节点,若能正常识别并显示延迟,说明内核支持新协议。
• 查看是否有 rule-providers 或规则集自动更新的设置项,这是判断规则系统是否为 mihomo 体系的直接依据。

对多数用户来说,内核差异不需要手动干预,只需要在选择客户端时确认其底层依赖的是持续更新的 mihomo,后续协议和规则的演进都会随客户端更新自动落地,不必单独关注内核本身的升级节奏。