Clash 原版、Meta 与 mihomo 内核区别对照:功能差异与选择依据
梳理三代内核的来龙去脉:原版停更后的现状、Meta 分支的扩展协议支持、mihomo 的更名与延续,按协议兼容性和维护状态给出当前应选哪个内核的判断依据。
内核谱系:从 Clash 原版到 mihomo 的演进脉络
市面上能查到的"Clash"其实指向三条不同的代码线,理解它们的先后关系是判断该用哪一个的前提。最早的 Clash 由原作者以 Go 语言编写,发布方式是命令行内核加第三方图形界面,长期是各平台客户端的默认底层。这一版本通常被称作"原版"或"Clash Premium/Core",它奠定了规则分流、代理组、订阅链接这套现在已经成为行业默认的交互模型。
2023 年前后,原作者的相关仓库从代码托管平台被整体移除,原版内核停止了公开的源码更新与版本发布。此后能下载到的原版二进制,基本都是社区在停更前保存的历史构建,或者第三方镜像仓库的存档,不再有新的协议支持或问题修复进入这条代码线。
在原版仍活跃的阶段,已经有开发者基于其代码拉出分支进行扩展,这个分支当时命名为 Clash Meta,重点补齐了原版没有跟进的新协议与 TUN 模式细节。原版停更之后,大量图形客户端把默认内核切换到了 Meta 分支,这也是"Meta 内核"这个说法在教程和论坛里高频出现的原因。Meta 分支后续经历了一次正式更名,项目继续以 mihomo 的名字维护,代码脉络和发布节奏是连续的,并非另起炉灶。也就是说,当前看到的"mihomo",在功能定位上就是升级换代后的 Meta,两者不是并列关系,而是同一条线的新旧称呼。
三代内核功能与协议支持对照
三条代码线在协议覆盖、运行模式和配置语法上都存在差异,下表列出实际使用中影响最大的几项。
| 能力项 | 原版(停更快照) | Meta / mihomo |
|---|---|---|
| 基础协议(Shadowsocks、VMess、Trojan) | 支持 | 支持 |
| VLESS | 不支持 | 支持 |
| Hysteria / Hysteria2 | 不支持 | 支持 |
| TUIC | 不支持 | 支持 |
| ShadowTLS / WireGuard 出站 | 不支持 | 支持 |
| TUN 模式(系统层接管流量) | 早期实验性,问题较多 | 作为稳定功能长期维护 |
| 规则提供者远程更新语法 | 基础版本 | 扩展字段更丰富,支持行为策略细分 |
| 配置覆写 / 脚本策略 | 不支持 | 支持 |
可以看到,分歧的核心不是"谁更快"或者"谁界面好看",而是协议清单和运行模式的代差。原版停更时新一代加密协议还没有普及,自然不会写进当年的代码。Meta 分支和后续的 mihomo 出现的价值,正是把这些新协议和更精细的流量控制能力补上,并持续跟进上游代理软件生态的变化。
维护状态与更新频率:能不能用得放心
选内核不只是看功能清单,更要看这条代码线现在是否还有人在改。三者的维护状态差异很直接。
- 原版:仓库已不再更新,现存的可执行文件是历史存档。不会有新的协议支持,也不会再收到针对已知问题的修复。如果某个订阅商换用了原版不认识的新协议,原版会直接连接失败,没有升级路径。
- Meta(历史名称):作为一个过渡阶段的名字,目前已经不再是活跃发布渠道,相关标签和说明在新版本中已经并入 mihomo 项目下,单独查找"Clash Meta"最新版本通常会被引导到 mihomo。
- mihomo:是当前实际持续发布的代码线,版本号按常规节奏迭代,新协议、新平台适配、问题修复都在这里落地。绝大多数还在活跃维护的图形客户端,底层内核都已经指向 mihomo,只是客户端界面上可能仍沿用"Meta 内核"这个历史说法。
判断一个客户端到底用的是哪条内核线,不要只看界面文案,以实际内核版本号或启动日志里的项目标识为准。部分教程和下载页仍沿用旧称呼,容易造成"到底是不是同一个东西"的困惑。
按场景给出的选型建议
结合协议兼容性和维护状态,给出几条可以直接照做的判断依据。
-
订阅只使用基础协议,且不需要 TUN 模式
如果上游节点全部是 Shadowsocks、VMess 或 Trojan,不涉及新协议,也不打算用系统层接管流量,理论上原版存档仍能连通。但要清楚这是在用一个不会再修复问题的历史版本,长期看存在协议淘汰或客户端适配脱节的风险,不建议作为长期方案。
-
订阅包含 VLESS、Hysteria2、TUIC 等新协议
这类协议原版完全不认识,连接会直接失败。必须选择基于 mihomo 内核的客户端,没有绕过空间。
-
需要 TUN 模式接管全局流量或做进程级分流
TUN 模式在 mihomo 上作为长期维护的稳定功能存在,配置字段和行为都更完整。原版的相关实现停留在早期阶段,不建议依赖其做精细分流。
-
不确定该选哪个,追求少踩坑
直接选用当前主流图形客户端默认集成的 mihomo 内核。它覆盖的协议范围最广,更新节奏稳定,遇到问题有持续修复的可能,不需要额外判断内核来源是否已经停更。
从原版配置迁移到 mihomo 的注意事项
如果手上的配置文件是早年基于原版规则写的,迁移到 mihomo 内核基本可以直接复用,但有几个字段差异值得核对一遍,避免规则组行为跟预期不一致。
- proxy-groups 里的分组类型在 mihomo 上扩展了更多策略选项,原版没有的字段会被忽略,不会导致配置报错,但也不会生效,建议逐条确认。
- rule-providers 的行为字段在新内核上更细,原有的简单规则集依然可以正常加载。
- 涉及新协议节点的条目,原版配置文件里通常不会出现,迁移后可以按需补充,不影响已有的其它节点。
一个简单的自查方式是先用新内核加载旧配置,观察启动日志是否有未识别字段的提示,再逐条比对官方文档里的字段说明,确认没有遗漏关键策略。
mihomo -d ./config -f ./config.yaml命令行方式启动时,日志会直接打印内核版本、加载的规则数量以及是否有解析失败的条目,这是核对内核版本和配置兼容性最直接的手段,比只看客户端界面上的名称更可靠。
结论:当下该怎么选
把上面的信息压缩成一句可执行的结论:原版内核已经停止维护,只适合明确知道自己在用旧版本、且订阅协议范围极其有限的场景;Meta 这个名字目前已经并入 mihomo,单独寻找已经没有意义;新装客户端或更换内核时,优先确认底层是否为 mihomo,这是协议覆盖最全、维护最活跃的选择,也是当前各平台图形客户端的主流默认配置。