三个名字,一条主线:Clash 内核的演进时间线
第一次接触 Clash 生态,最容易卡住的不是配置,而是名字:教程里写 Clash,下载页写 Clash Meta,新版本客户端的界面里又冒出 mihomo。三者不是三个竞争项目,而是同一个内核在不同阶段的称呼。先把时间线摆清楚,后面的选择都是顺理成章的事。
| 时期 | 名称 | 维护方 | 状态 |
|---|---|---|---|
| 2018 – 2023 | Clash(原版) | Dreamacro | 已停止维护 |
| 2022 – 2024 | Clash Meta | MetaCubeX 团队 | 已更名 |
| 2024 至今 | mihomo | MetaCubeX 团队 | 维护中 |
一句话记法:原版 Clash 是共同的前身,Clash Meta 是接棒者,mihomo 是 Meta 的新名字。今天新装的客户端,内核几乎都是 mihomo。
原版 Clash:规则代理的奠基者,已停止维护
原版 Clash 由 Dreamacro 用 Go 语言编写,2018 年发布。它确立了沿用至今的工作范式:一份 YAML 配置文件描述节点、策略组与分流规则,入站流量按规则被送往直连、代理或拒绝。混合端口、外部控制器 API、按域名与 IP 分流这些设计,都是原版定下的基调。
原版分两条线:开源的核心,以及闭源的 Clash Premium。Premium 独占 TUN 模式与脚本能力,Clash for Windows、ClashX 等早期客户端集成的正是它。
2023 年 11 月,作者归档仓库并清空发布页,原版正式停止维护。含义很直接:新协议不会加入,已有实现的缺陷不会修复,建立在其上的客户端也陆续停更。今天再装一个原版内核的客户端,多数场景还能跑,但协议覆盖面停留在 2023 年,后续不会再有变化。
Clash Meta:接棒的增强分支
在原版停更之前,MetaCubeX 团队已经基于原版 fork 出 Clash Meta 继续开发;原版停更后,Meta 顺势成为事实上的主线。相对原版,它的关键增量集中在四个方面:
- 协议面:新增 VLESS(含 XTLS Vision、Reality)、Hysteria 与 Hysteria2、TUIC、WireGuard、ShadowTLS、AnyTLS,原版之后出现的主流协议基本覆盖。
- TUN 模式:内置且免费开放,不再依赖闭源 Premium,可接管系统全局流量。
- 规则面:
rule-providers与proxy-providers向所有用户开放,支持域名嗅探(sniffer)与 GEOSITE 规则集。 - 体验面:
unified-delay统一测速口径,tcp-concurrent并发建连,find-process-mode按进程分流。
配置层面,Meta 大体是原版的超集:为原版编写的配置大多可以直接运行;反过来,带 Meta 专属字段的配置拿到原版核心上,启动即报错。
mihomo:Clash Meta 的现行名称
2024 年,Clash Meta 更名为 mihomo,仓库迁至 MetaCubeX/mihomo,版本号沿原有线路继续递增。改名不改代码:同一批维护者、同一份配置语法、同一条发布节奏,文档站 wiki.metacubex.one 同时覆盖新旧两个名字。
实际使用中会遇到名称混用:旧版本日志打印 Clash Meta,新版本打印 Mihomo;有的客户端界面写 Meta 内核,有的写 mihomo 内核——指的都是同一个程序。看到 mihomo v1.18、v1.19 这类版本号,即可确认是这条线的现行版本。
客户端与内核对照表
客户端是外壳,内核才是实际处理流量的进程。常见客户端的内核归属如下:
| 客户端 | 内置内核 | 维护状态 |
|---|---|---|
| Clash Verge Rev | mihomo(原 Clash Meta) | 维护中 |
| FlClash | mihomo | 维护中 |
| mihomo party | mihomo | 维护中 |
| Clash for Windows | Clash Premium(原版) | 已停更 |
| ClashX 系列 | 原版或 Meta | 已停更 |
| Clash Meta for Android | Clash Meta | 已停更 |
判断一个客户端是否值得新装,先看内核:基于 mihomo 的客户端能跟上协议演进;基于原版内核的客户端,功能定格在停更那一刻。详细的客户端横向对比见本站客户端对比页。
确认当前运行的内核版本
以 Clash Verge Rev 为例,三条途径可查:
- 设置页:「设置」中的「Clash 内核」区块显示当前内核类型与版本号,并可在正式版与 Alpha 通道之间切换。
- 日志页:内核启动时会把名称与版本写进日志首行,日志等级调到 Info 即可看到。
- 外部控制器:内核运行期间,直接查询版本接口。
$ curl http://127.0.0.1:9097/version
{"premium":true,"version":"Mihomo Meta v1.18.7"}9097 是 Clash Verge Rev 的默认外部控制器端口;若在设置里改过端口,以实际值为准。返回的 version 字段以 Mihomo 开头,即说明跑在 mihomo 线上。
换内核前的配置兼容性检查
手里有一份老配置、打算从原版内核迁到 mihomo,按三个方向核对即可:
- 原版字段在 mihomo 上几乎全部兼容:
port、mixed-port、proxies、proxy-groups、rules原样可用。 - mihomo 专属字段不要写进给原版用的配置:
unified-delay、tcp-concurrent、sniffer、tun配置块、geodata-mode等,原版解析到未知字段会直接退出。 - 规则集写法以 mihomo 文档为准:
RULE-SET、GEOSITE依赖 rule-providers 与 geodata,原版开源核心不支持。
订阅与内核要配套
当前订阅服务大多按 mihomo 语法下发。把订阅交给原版内核的客户端,常见结果是启动报错或节点全部不可用。新装客户端,直接选 mihomo 内核即可。字段细节可对照本站配置参考页逐项核对。
迁移时的常见疑问速答
第一问:老配置要不要重写?多数情况不用。mihomo 对原版字段向下兼容,直接导入即可运行;真正要动手的只有一种场景——你想用上 sniffer 域名嗅探、tun 虚拟网卡这类新能力,才需要在配置里补上对应字段。第二问:换内核会不会影响订阅?不会,订阅链接本身与内核无关,拉取下来的 YAML 由客户端交给内核解析,只要内核认得字段就能跑。第三问:延迟测速结果为什么和以前不一样?mihomo 默认启用统一延迟(unified-delay),把握手耗时从测速里剔除,数值普遍比原版内核测出来的低,这是统计口径变化,不代表节点变快,横向对比节点优劣时不受影响。第四问:客户端界面上没写内核版本怎么办?按上文的 curl 方法查外部控制器接口即可,任何 Clash 系客户端都适用。把这四个问题弄清,迁移基本不会踩坑。
收束成一句:原版 Clash 是历史,Clash Meta 是曾用名,mihomo 是现在进行时。选客户端认准 mihomo 内核,配置写法、协议支持、文档示例都围绕它展开。