Clash、mihomo、Verge Rev 是什么关系:开源项目谱系与内核演进梳理
很多人第一次接触 Clash 生态时都会被“到底该装哪个”问住:Clash、Clash Meta、mihomo、Clash Verge Rev、FlClash……名字相似却指向不同的项目。这篇文章按时间线梳理内核与客户端的继承关系,说明谁是谁的延续,以及如何判断一个项目是否还在维护。
原始 Clash 内核的诞生与停止维护
最早的 Clash 是一个用 Go 语言编写的规则代理工具,核心能力是按域名、IP 段、GeoIP 等条件把流量分流到不同出口,并支持 Shadowsocks、VMess、Trojan 等多种协议的统一管理。它的设计思路是把“规则引擎”和“协议实现”解耦:配置文件里写规则,内核负责匹配和转发,用户不需要关心底层握手细节。这套架构后来被几乎所有 Clash 系客户端沿用,是理解整个生态的起点。
原始仓库在维护多年后被作者归档,不再接受新特性提交,也不再修复新出现的兼容性问题。对普通用户而言,直接的影响是:如果继续使用基于这个内核的老客户端,遇到新协议不支持、新系统版本适配问题时,不会再有官方更新来解决。这也是社区分叉大量出现的直接原因——核心能力没有消失,只是需要新的维护者接手。
提示:“内核归档”不等于“无法使用”,已经下载好的旧版本仍能运行,但长期来看会逐渐落后于系统与协议的更新节奏,建议优先选择仍在活跃维护的分支。
Clash Premium 与开源版的分野
在原始项目发展中期,作者曾推出过闭源的 Premium 内核,加入了 TUN 模式、更完整的规则订阅、脚本扩展等高级能力,与完全开源的基础版并行存在。这一段历史造成了后续社区分叉的两个方向:一部分项目专注在开源基础上补齐 Premium 时代的功能(比如自己实现 TUN 支持),另一部分则围绕如何整合、复刻这些高级特性展开。
这也是为什么现在市面上能看到“功能几乎一样、但代码来源不同”的多个客户端——它们各自在开源生态的不同分支上,把 Premium 时代留下的功能需求重新实现了一遍。对使用者来说,不需要纠结历史细节,只需要确认当前使用的版本是否支持 TUN 模式、规则订阅、脚本策略这几项关键能力即可。
mihomo 内核:社区延续的主线
原始内核归档后,社区里活跃度最高、更新最频繁的延续项目最终发展并更名为 mihomo。它在功能上完整覆盖了原有的规则匹配、协议支持,并持续跟进新协议(如 Hysteria2、TUIC 等)和系统层适配(如 macOS/Windows 的 TUN 权限模型变化)。目前绝大多数仍在积极更新的 Clash 系 GUI 客户端,底层调用的都是 mihomo 内核,而不是最初那个已归档的版本。
理解这一点很重要:很多客户端界面上仍然沿用“Clash”这个名字做产品标识,但实际运行的内核早已切换到 mihomo。判断一个客户端是否跟得上协议更新,本质上是判断它绑定的内核版本更新频率,而不是看界面上写的品牌名字。
| 阶段 | 关键项目 | 状态 |
|---|---|---|
| 早期 | 原始 Clash 内核 | 已归档,不再更新 |
| 过渡期 | Clash Premium(闭源) | 历史版本,不再迭代 |
| 当前主线 | mihomo 内核 | 活跃维护,主流客户端底层 |
GUI 客户端谱系:谁在用什么内核
内核之上是各家 GUI 客户端,它们负责界面、订阅管理、系统代理设置这些用户直接接触的部分,底层则打包调用某个版本的内核。梳理清楚这一层关系,才能判断一个客户端“新不新”。
- Clash for Windows(俗称 CFW):早期最流行的桌面客户端之一,随着原始内核停止维护,该项目本身也进入停更状态,不建议新用户继续选择。
- Clash Verge / Clash Verge Rev:基于 Tauri 框架的轻量桌面客户端,原项目沉寂后由社区以 Rev(revive,复兴)分支延续,持续跟进 mihomo 内核更新,是目前 Windows/macOS/Linux 上活跃度较高的选择之一。
- ClashX / ClashX Meta:macOS 平台上历史悠久的客户端,后续版本同样转向以 mihomo 为底层内核。
- FlClash:用 Flutter 编写的跨平台客户端,界面在 Windows、macOS、Android 上保持一致,同样基于 mihomo 内核构建。
- Clash Plus:iOS 平台上通过 App Store 分发的客户端,遵循 iOS 系统的网络扩展与 VPN 权限模型,界面针对触屏和小屏幕做了专门适配。
可以看到,这些客户端的关系不是“谁抄谁”,而是同一套内核能力在不同平台、不同技术栈下的界面实现。选择哪一个,更多取决于操作系统、界面偏好和更新频率,而不是纠结“正统与否”。
如何判断一个 Clash 相关项目是否仍在维护
面对一堆相似的项目名字,与其去追溯完整历史,不如掌握几个实用的判断方法:
- 看更新时间
近几个月内是否有新版本发布,是最直接的信号。长期停更但仍能下载的版本,大多只适合临时应急使用。
- 看内核绑定版本
客户端设置或关于页面通常会标注绑定的内核版本号,可以对照是否为较新的 mihomo 版本。
- 看协议支持范围
如果新出现的代理协议在客户端里完全找不到对应选项,大概率是内核版本偏旧。
- 看系统适配情况
操作系统升级后(尤其是 macOS 的网络扩展权限、Windows 的 TUN 驱动签名要求),客户端是否同步做了适配,也是维护活跃度的体现。
注意:项目名字里带“Clash”不代表一定活跃维护,也不代表功能落后;判断标准始终是更新记录和内核版本,不是名字本身。
对于日常使用而言,不需要成为开源历史专家,只需要在下载页选择当前仍在积极更新的客户端版本,配合有效的订阅链接,就能获得规则分流、TUN 模式等完整能力。技术选型的细节留给项目维护者,普通用户关心的其实只是“稳定好用、跟得上系统更新”这两点。