2026-06-15 生态选型 预计阅读 9 分钟

Clash、mihomo、Verge Rev 是什么关系:开源项目谱系一次理清

原版 Clash 归档后,内核与图形客户端各自演化出多条分支。本文梳理 mihomo 内核与 Verge Rev、FlClash、Nyanpasu 等 GUI 项目的继承关系,帮助读者按平台选对客户端。

很多人第一次接触 Clash 生态时会被搞晕:搜索"Clash 下载"能找到十几个不同名字的软件,界面各不相同,GitHub 仓库也分散在不同账号下。这种混乱不是偶然,而是有明确的历史脉络——原作者归档仓库之后,社区接力维护形成了今天的格局。理清这条脉络,才能明白为什么某些客户端更新频繁、某些已经停更,以及不同平台该优先选哪一个。

SEC-01

原版 Clash 归档:分裂的起点

最初的 Clash 项目由 Dreamacro 开发,使用 Go 语言编写,核心思路是"基于规则的流量分流":配置文件里写明域名或 IP 段该走哪个代理节点,内核按规则逐条匹配后转发流量。这套设计被后续所有分支完整继承,是理解整个生态的基础。

2023 年前后,原始仓库因为一些外部原因被归档(archive),仓库转为只读状态,不再接受新的提交。这对当时依赖 Clash 内核的所有图形客户端都是一次冲击——内核不再更新,意味着新的协议支持、新的规则语法、安全修复都无法进入官方版本。社区随即出现了两条应对路径:

  • 继续使用旧内核:部分客户端在归档前的最后版本基础上原地冻结,不再跟进新特性,长期使用会逐渐遇到协议不兼容问题。
  • 切换到社区维护的分支内核:这是目前活跃项目普遍采用的路线,也是本文重点介绍的 mihomo。
NOTE

选择客户端时,判断依据不是"名字里有没有 Clash 字样",而是它底层依赖的内核是否仍在积极维护。这一点比界面美观程度更影响长期可用性。

SEC-02

mihomo:社区接力的核心内核

mihomo 是原 Clash Meta 项目更名后的延续,由社区团队维护,目前是最活跃、更新最频繁的开源内核。它在原版 Clash 的规则分流基础上,补齐并强化了以下能力:

  • TUN 模式:在系统网络层建立虚拟网卡,实现全局流量接管,不再依赖单个应用手动设置代理,对不支持系统代理设置的程序同样生效。
  • 更完整的协议支持:VMess、VLESS、Trojan、Hysteria、Hysteria2、TUICon 等协议逐步补齐,跟进速度明显快于停更前的原版内核。
  • 规则集扩展:支持 GEOSITE、GEOIP 等远程规则集格式,便于订阅方按地区与服务归类维护规则,不需要客户端手工列举每一条域名。
  • 脚本与进阶策略:提供 Script 类规则和更灵活的策略组嵌套能力,满足复杂分流场景。

需要强调的是,mihomo 本身是一个没有图形界面的内核程序,日常使用的各类客户端(Verge Rev、FlClash、Nyanpasu 等)都是在 mihomo 之上包装出的图形外壳,负责配置管理、节点展示、订阅导入、流量统计等交互层功能,真正执行代理与分流逻辑的仍是内核本身。

mihomo

内核与协议

原 Clash Meta 更名后的社区维护内核,负责协议解析、规则匹配与流量转发,是当前主流图形客户端共同依赖的底层引擎。

SEC-03

图形客户端各自的定位

内核统一之后,不同图形客户端的差异主要体现在开发语言、界面框架和目标平台上。下面按项目梳理各自特点,方便按使用场景挑选。

Verge Rev(clash-verge-rev)

使用 Tauri 框架开发,前端界面基于 Web 技术栈,后端用 Rust 编写,体积较传统 Electron 客户端更轻。它是目前 Windows、macOS、Linux 三端更新最规律的桌面客户端之一,配置文件采用可视化编辑与 YAML 源码编辑双模式切换,方便同时满足新手和习惯手写配置的用户。策略组、连接详情、日志面板等信息展示也比较完整。

FlClash

基于 Flutter 框架开发,最大的特点是跨平台代码高度复用——同一套界面代码可以编译出 Windows、macOS、Linux、Android 多个平台的客户端,视觉风格在各平台上保持一致。对于需要在多台不同系统设备间切换、又希望操作习惯统一的用户,这类客户端能减少重新适应界面的成本。

Nyanpasu(clash-nyanpasu)

同样基于 Tauri 框架,界面设计上更强调动效与主题自定义,支持配置文件的可视化管理与订阅自动更新。它与 Verge Rev 在技术选型上接近,但界面风格与部分交互细节走了不同路线,适合偏好个性化外观的用户。

移动端与其他平台

Android 平台除 FlClash 外,还有多个基于 mihomo 内核的独立客户端,普遍支持 TUN 模式下的全局代理和按应用分流。iOS 平台的选择相对有限,多数客户端通过 App Store 分发,界面风格更贴近系统原生设计规范,配置管理方式也更强调订阅链接的一键导入。

SEC-04

配置文件与订阅:跨客户端通用

由于所有主流客户端最终都调用 mihomo 或兼容内核解析配置,YAML 格式的配置文件和订阅链接在这些客户端之间基本可以直接互通。一份标准配置通常包含以下几个核心字段:

port: 7890
socks-port: 7891
mode: rule
log-level: info
proxies:
  - name: "节点示例"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies: ["节点示例"]
rules:
  - DOMAIN-SUFFIX,example.com,自动选择
  - MATCH,DIRECT

这意味着从一个客户端迁移到另一个客户端时,通常不需要重新配置代理节点,直接导入原有的订阅链接或本地配置文件即可继续使用。真正需要注意的差异集中在客户端专属的界面设置项上,例如系统代理开关方式、TUN 模式的启用入口、日志保留策略等,这些属于外壳层功能,不会随内核切换而自动迁移。

SEC-05

按平台选择客户端的实用建议

  1. 确认平台覆盖范围

    先明确自己需要覆盖的系统:仅 Windows 单平台,还是 Windows、macOS、Android 多端同时使用。多平台场景优先考虑同一项目的跨平台版本,减少配置文件在不同客户端间转换的麻烦。

  2. 检查项目更新频率

    在 GitHub 仓库页面查看最近一次发布(Release)的时间,长期无更新的客户端即便界面正常打开,也可能因内核过旧而无法解析新的协议或规则语法。

  3. 验证 TUN 模式支持

    如果需要全局流量接管而不是单应用代理,确认目标客户端明确支持 TUN 模式,并在系统层面完成对应的权限授予(如 Windows 上的管理员权限、macOS 上的网络扩展授权)。

  4. 保留原配置文件

    更换客户端前导出或备份现有订阅链接与本地规则,便于新客户端安装完成后直接导入,避免重新整理节点信息。

WARN

不同客户端对规则语法的扩展字段支持程度略有差异,例如部分脚本类规则或较新的策略组类型并非所有客户端都完整支持。切换客户端后建议先用简单配置测试连接是否正常,再逐步导入完整规则集。

SEC-06

小结:认准内核,再挑外壳

整理下来可以得到一条清晰的判断路径:Clash 确立了基于规则的分流架构 → mihomo 作为社区接力的内核持续实现协议与功能更新 → Verge Rev、FlClash、Nyanpasu 等图形客户端在 mihomo 之上构建各自的界面与交互体验。选择客户端本质上是在选择一层界面外壳,只要内核相同,配置文件通用,不同客户端之间的迁移成本很低。真正值得花时间比较的,是界面是否符合自己的操作习惯、目标平台是否被稳定支持,以及项目是否仍在活跃维护。

下载客户端