mihomo 内核与原版 Clash 有什么区别?Meta 分支特性一览

从 Clash 到 Clash Meta 再到 mihomo:一段内核演进史

原版 Clash 内核由 Dreamacro 发起,采用 Go 语言实现,确立了 config.yaml 的基本结构、代理组抽象与规则匹配引擎,是后续所有分支的起点。随着协议演进(如 Hysteria2、TUIC、WireGuard 陆续出现)与用户对更细粒度控制的需求增长,社区在原版基础上开出了 Clash Meta 分支,持续合并新协议、新规则类型与性能优化。原版仓库自 2022 年之后更新趋缓,而 Clash Meta 在活跃维护下逐步反超原版的功能覆盖面,并最终改名为 mihomo,作为独立项目继续演进。

目前"mihomo 内核"这个说法,在语境上基本等同于早期的"Clash Meta 内核"——两者是同一条开发脉络的不同阶段命名,协议前缀、配置字段大体兼容,只是包体、版本号与部分默认行为随迭代发生了变化。理解这段脉络,有助于判断某个客户端所标注的"内核版本"到底对应哪一套能力集。

出站协议支持:mihomo 新增了哪些协议

协议支持是两套内核最直观的差异。原版 Clash 内核聚焦于 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等较早成熟的协议,配置字段相对固定,长期没有大的扩展。mihomo 在此基础上补齐了近年新增的出站类型,常见的包括:

• Hysteria / Hysteria2:基于 QUIC 的拥塞控制协议,在弱网、高丢包链路下表现优于传统 TCP 类协议。
• TUIC:同样构建在 QUIC 之上,专注于低延迟场景,适合对交互延迟敏感的使用场景。
• WireGuard:作为出站协议直接接入,不再需要额外的系统级 WireGuard 客户端配合。
• VLESS / VMess 的流控扩展,以及 ShadowTLS 前置层,用于进一步混淆流量特征。
• Snell v4 等协议的新版本字段支持。

这意味着如果订阅节点使用了上述较新协议,只有 mihomo 内核能正确解析并建立连接;原版内核遇到未知协议类型时,通常会直接跳过该节点或报错,导致代理组里出现"节点数量对不上"的现象。

规则集与 GEO 数据:更新机制的差异

规则分流依赖 GEOIP、GEOSITE 数据库与规则集(rule-provider)判断域名或 IP 归属。原版内核的 GEO 数据格式相对固定,更新频率取决于内核自身发布节奏;mihomo 支持更灵活的规则集来源与格式:

1. 支持 rule-set 引用远程规则集,并可指定 behavior(domain / ipcidr / classical)与更新间隔,规则内容与内核版本解耦,不需要等内核发新版本就能获取最新分流规则。
2. 支持 MRS(mihomo 专用二进制规则格式),比传统文本规则加载更快,尤其在规则条目达到数万级别时,启动与匹配性能差异明显。
3. GEO 数据库来源可自定义,允许指向社区维护的 GeoIP2/GeoSite 数据仓库,而不必依赖内核内置的固定版本。

对普通用户而言,直观的体现是:使用 mihomo 内核的客户端在"规则提供者"设置里,通常能看到更丰富的行为选项与更短的更新周期;而基于原版内核的客户端,规则更新往往要跟随整个客户端版本一起发布。

TUN 模式与网络栈:mihomo 的底层改进

TUN 模式让 Clash 能接管系统级流量,而不仅是浏览器等支持代理设置的应用。原版内核对 TUN 的支持相对基础,依赖系统路由表手动配置;mihomo 在这一层做了较多改进:

• 内置 自动路由管理,创建虚拟网卡后自动写入并在退出时清理路由表项,减少手动配置出错的概率。
• 支持在 gVisor 用户态栈与 系统原生栈(system stack)之间切换,前者兼容性更好,后者在部分平台上性能更优,可按需取舍。
• 增强了 DNS 劫持与 Fake-IP 池与 TUN 模式的配合,减少因 DNS 解析路径不一致导致的连接失败。
• 对 Android、macOS 等平台的虚拟网卡权限处理进行了适配优化,降低系统层面被中断连接的概率。

这也是为什么绝大多数需要"全局透明代理""接管系统全部流量"场景的客户端,都会优先选择 mihomo 内核——TUN 模式的稳定性直接影响日常使用体验。

RESTful API 与配置能力增强

两套内核都提供基于 HTTP 的外部控制接口(通常监听在 127.0.0.1:9090 一类地址),供客户端界面查询代理状态、切换节点、查看日志。mihomo 在这套 API 之上做了扩展:

• 新增更细粒度的接口,例如按分组查询延迟、按规则提供者单独触发更新,而不必重载整份配置。
• 支持 Script 规则与 Lua 逻辑判断等高级匹配方式,允许在规则文件里写简单脚本逻辑,而不是只能罗列静态规则。
• 对 Provider 覆盖(override)能力做了增强,可以在不修改订阅本身的前提下,通过本地覆盖规则调整某些字段(如强制启用 UDP、修改测速 URL)。

这些能力主要面向进阶用户与客户端开发者,普通用户不需要直接调用 API,但客户端界面上"测速方式可自定义""某个代理组支持脚本选择器"这类设置项,背后往往就是内核 API 扩展带来的。

主流客户端内置的是哪套内核?

选客户端时,内核版本决定了功能上限。下表列出常见客户端与其对应内核情况,供快速核对:

需要注意的是,同一个客户端项目也可能随版本迁移内核,例如从早期依赖原版内核转向内置 mihomo。下载前查看客户端发布说明或设置页里的"内核版本"字段,是确认实际能力的最可靠方式,比单看客户端名称更准确。

该如何选择?

如果订阅节点使用了 Hysteria2、TUIC、WireGuard 等较新协议,或者需要稳定的全局 TUN 模式、更灵活的规则集更新,选择内置 mihomo 内核的客户端几乎是唯一合理选项。如果只是使用 Shadowsocks、VMess 等经典协议,并且客户端界面、交互习惯已经比较熟悉,原版内核的客户端也能满足基础的分流与切换需求,不必强行迁移。

两套内核都遵循 GPL-3.0 开源协议,配置文件语法高度兼容,大多数 config.yaml 可以在两者之间直接迁移,只是涉及新协议或新规则语法的部分,原版内核会无法识别,这一点在切换客户端前值得提前确认。