Clash 原版、Meta 与 mihomo 内核区别对照:功能、协议与配置兼容性

一条演进线:从 Clash 到 Clash Meta 再到 mihomo

要理清三个名字的关系,先看时间顺序。最早的 Clash(通常称为「原版」或「Clash Premium」)由个人开发者维护多年,奠定了规则分流、策略组、Provider 订阅这套基础架构,几乎所有后续客户端的配置语法都以它为蓝本。原作者在 2023 年停止更新并删除代码仓库,原版内核就此定格,不再获得新协议、新字段的支持。

停更之后,社区里最活跃的分叉项目是 Clash Meta(也叫 Clash.Meta),它在原版代码基础上继续维护,补齐了原版一直缺失的一些能力,同时保持配置语法高度兼容,老用户几乎不用改配置就能切换过去。Clash Meta 运营一段时间后,项目正式改名为 mihomo,名字变了但仓库、维护团队与技术路线是连续的,可以理解为「Clash Meta 的延续」,而不是另起炉灶的新项目。

所以现在市面上大多数还在更新的 Clash 系客户端(桌面端、路由器固件插件、部分安卓客户端),底层跑的内核基本是 mihomo,只是外壳套了不同的图形界面和品牌名。理解这条演进线,再看后面的功能对照会更容易对号入座。

协议支持差异:原版停更前的能力边界

协议支持是三代内核最直观的差异点。原版内核在停更时支持的协议以 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 为主,这些协议覆盖了当时绝大多数订阅场景,但停更之后就再没有增量。Clash Meta 接棒后陆续加入了 VLESS、Hysteria、Hysteria2、TUIC、WireGuard 等较新的协议,mihomo 延续这条路线继续更新,新增协议特性与握手参数支持的速度明显快于原版停更前的节奏。

换个角度看这张表:如果你的订阅节点里出现了 VLESS 或 Hysteria2 协议,原版内核根本无法解析这类节点,客户端会直接报错或跳过该节点;这也是很多人升级客户端却发现「节点全部失效」的直接原因——不是订阅坏了,是内核跟不上协议。

TUN 模式与内核架构:Meta/mihomo 的关键升级

TUN 模式(虚拟网卡模式)决定了客户端能不能接管系统层面的全部流量,而不只是浏览器或指定应用的流量。原版内核也带 TUN 支持,但实现相对基础,进程识别能力有限,遇到需要按应用做分流的场景(比如只让某个游戏走代理、其他应用直连)时经常力不从心。

Clash Meta 在 TUN 模式上做了系统性重写,引入了更完整的进程匹配机制,可以按进程名、路径甚至包名过滤流量,配合规则里的 process-name、process-path 字段实现精细分流。mihomo 继续在这个基础上优化性能和兼容性,尤其是在 Windows 和 macOS 上的 TUN 稳定性、与系统防火墙的协同、IPv6 流量接管等方面都比原版成熟不少。

另外一个容易被忽略的架构差异是内核对多核并发和内存占用的优化。mihomo 在长期运行、节点数量较多的场景下,内存增长曲线比原版更平稳,这对需要 7x24 小时挂机的路由器或 NAS 场景尤其重要。如果你的用法是常年后台运行、偶尔切换策略组,选新内核在稳定性上通常更有保障。

配置文件字段兼容性:哪些字段能直接迁移

好消息是,三代内核的配置文件语法高度同源,核心结构没有断裂式变化。port、socks-port、mode、proxies、proxy-groups、rules 这些基础字段在原版、Meta、mihomo 里写法完全一致,一份写给原版的配置,拿到 mihomo 上大概率能直接加载并正常工作。

差异主要出现在新增字段和新协议专属参数上。举几个实际例子:

• tun 段里的 stack(选择 gVisor 或 System 网络栈)、auto-route、dns-hijack 等子字段,原版没有对应实现,写在原版配置里会被直接忽略甚至报错。
• proxies 列表里 type: vless、type: hysteria2 这类节点声明,原版内核无法识别 type 字段的这些取值,加载时会跳过该节点或整段报错。
• dns 段里的 enhanced-mode: fake-ip 两代内核都支持,但 mihomo 在 fake-ip-filter 的匹配规则上做了细化,部分写法在原版里效果会有出入。
• 规则集(rule-provider)的 behavior 字段取值在新内核里支持更多类型,原版仅兼容基础的 domain、ipcidr、classical 三种。

实操建议是:从原版迁移到 mihomo 时,配置文件基本可以原样搬过去,只需要额外补上 tun 段和新协议节点即可;反过来如果要把一份 mihomo 配置降级用在原版内核上,则必须先删除新协议节点和 tun 高级字段,否则会导致整份配置加载失败。

该怎么选:场景对照建议

结合上面的协议支持、TUN 能力和配置兼容性差异,给出几条实用的选型参考:

1. 订阅节点包含 VLESS、Hysteria2、TUIC 等新协议:必须选 mihomo 内核,原版内核无法解析这些节点,不存在「凑合能用」的空间。
2. 需要按应用做全局代理(游戏走代理、其他直连):选支持完整进程级 TUN 的 mihomo,原版的进程匹配能力有限,规则写了也可能不生效。
3. 长期挂在路由器或 NAS 上跑:优先 mihomo,内存与并发表现更稳定,长时间运行的可靠性更高。
4. 只用最基础的 Shadowsocks/VMess 节点,配置从多年前就没变过:两代内核都能跑,但原版已停止更新,长期看仍建议迁移到持续维护的 mihomo,避免未来订阅升级协议时无法兼容。
5. 拿到别人分享的老配置文件不确定兼容性:先用文本编辑器搜索配置里是否出现 vless、hysteria、tuic 关键字,以及是否有 tun: 段,出现即说明这份配置是为新内核写的。

目前主流的 Clash 系客户端,不管界面叫什么名字,底层绝大多数都已经切换到 mihomo 内核,这也是本站下载页默认推荐的内核路线。选内核本质上是在选协议覆盖面和长期维护保障,新内核在这两点上都占优,原版更多是作为历史参照存在。