Clash、mihomo、Verge 到底什么关系:开源生态项目脉络梳理

先分清三层:内核、图形客户端与配置

理解 Clash 生态最有效的方法,不是记住一串相似名称,而是先把软件拆成三层。最底层是代理内核,负责读取 YAML 配置、建立代理连接、匹配规则、执行 DNS 查询以及接管系统流量。中间层是图形客户端,负责订阅管理、托盘菜单、系统代理开关、日志展示和更新操作。最上层则是配置与订阅,其中包含节点、策略组、规则和 DNS 参数。

原始 Clash 与 mihomo 属于内核层。Clash Verge、Clash Verge Rev、ClashX、FlClash 等名称通常指图形客户端。订阅链接则是配置来源,既不是内核,也不是某个固定客户端的组成部分。同一份基础配置可能被多个客户端载入,但能否完整运行,取决于底层内核是否支持其中使用的字段。

代理内核: 解析配置并转发流量。常见名称包括原始 Clash、Clash.Meta 与后续的 mihomo。
图形客户端: 为内核提供窗口、托盘、订阅管理、系统代理和 TUN 开关,本身不等同于代理协议实现。
订阅与配置: 以 YAML 或订阅响应形式提供节点、策略组、规则、DNS 与流量接管参数。

从原始 Clash 到 mihomo 的项目脉络

原始 Clash:配置语法与规则模型的起点

由 Dreamacro 开发的原始 Clash 奠定了今天仍被广泛使用的配置结构:以 proxies 定义节点,以 proxy-groups 组织选择与自动测试,再由 rules 按顺序决定流量去向。常见的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 和末尾兜底规则,都来自这套模型。

原始开源 Clash 的常见最终版本标识为 v1.18.0。另有曾经单独发布的 Clash Premium 构建,公开版本可见 2023.08.17。原项目在 2023 年停止持续维护后,它仍然具有重要的配置兼容意义,但已不适合作为观察新协议、新规则能力和新平台修复的唯一依据。

Clash.Meta:兼容基础上的功能扩展

Clash.Meta 最初可以理解为兼容 Clash 配置体系的扩展内核。它保留常见的策略组与规则写法,同时持续加入更完整的 TUN、DNS、规则集和协议支持。很多配置中的 rule-providers、fake-ip-filter、进程匹配以及更细的网络栈选项,在 Meta 系内核上有更积极的维护。

这里的“兼容”不代表所有方向都能互换。基础 Clash 配置通常可以被 mihomo 读取,但使用 mihomo 扩展字段的配置,放回旧版原始 Clash 时可能出现“字段无法识别”“代理类型不支持”或配置载入失败。迁移时应把兼容关系理解为从旧语法向新内核较顺畅,而不是双向完全一致。

mihomo:Clash.Meta 的后续名称

Clash.Meta 后续更名为 mihomo,项目由 MetaCubeX 社区继续维护。名称变化没有把它变成另一套完全不同的配置体系:不少客户端、配置转换工具和日志页面仍会保留 Meta、Clash Meta 或 Meta Core 等旧称。看到这些词时,通常需要结合具体版本号判断,而不是把它们当作三个互不相关的内核。

因此,当前常见链路可以概括为:原始 Clash 提供基础配置模型,Clash.Meta 在兼容基础上扩展能力,mihomo 延续 Clash.Meta 的开发。客户端若标注“mihomo 内核”,通常意味着它面向这条仍在更新的分支。

Verge、ClashX 与 Clash for Windows 分别是什么

项目	所在层级	典型平台	核心关系	选择时关注点
Clash	内核	命令行、多平台构建	原始项目	已停止持续维护,主要用于理解基础兼容
Clash.Meta / mihomo	内核	Windows、macOS、Linux、移动端	Meta 后续更名为 mihomo	版本更新、配置扩展、TUN 与 DNS 能力
Clash Verge	桌面图形客户端	Windows、macOS、Linux	通过内核执行代理功能	原项目维护状态与后续分支需要分开判断
Clash Verge Rev	桌面图形客户端	Windows、macOS、Linux	通常配合 mihomo	内核版本、服务模式、TUN 权限与系统兼容性
ClashX	macOS 图形客户端	macOS	封装 Clash 系内核	系统版本、内核年代与配置字段兼容性
Clash for Windows	桌面图形客户端	Windows、macOS、Linux	历史上集成 Clash 系内核	最终常见版本为 0.20.39,项目已停止更新

Clash Verge 与 Clash Verge Rev

Clash Verge 是采用桌面 Web 技术构建的跨平台图形客户端,负责订阅、策略选择、系统代理和配置编辑。原 Clash Verge 项目停止活跃后,Clash Verge Rev 作为后续维护分支延续了相近的操作方式。两者名称接近,但发布仓库、版本序列和维护状态并不相同,下载时不能只看应用图标。

在 Clash Verge Rev 中,用户通常可以从「设置」→「Clash 设置」查看端口、外部控制器和内核相关参数,从「设置」→「系统设置」管理开机启动或服务模式。不同版本的翻译可能略有调整,但“设置页中的内核版本”比安装包名称更能说明实际能力。启用 TUN 时,Windows 往往还需要安装并启动服务模式,macOS 则需要完成系统权限授权。

ClashX:面向 macOS 的菜单栏客户端

ClashX 的重点是 macOS 菜单栏体验。它把配置切换、策略组选择、系统代理与日志入口放进状态栏菜单,适合以系统代理为主要接管方式的使用场景。ClashX、ClashX Pro 以及社区延续版本不能只凭名称判断功能,需要分别确认其内核类型、最后更新时间和对当前 macOS 的支持情况。

旧版 ClashX 能读取许多经典 Clash 配置,但遇到仅由 mihomo 支持的协议、规则集行为或 DNS 字段时,可能无法完整载入。若订阅说明明确要求 Meta 或 mihomo 内核,应选择明确集成对应内核的客户端,而不是通过反复删字段让旧客户端勉强启动。

Clash for Windows:历史影响大,但不再更新

Clash for Windows 常缩写为 CFW,是很多用户最早接触的桌面客户端。它提供 Profiles、Proxies、Connections、Logs 和 Settings 等页面,并推广了“订阅导入后直接切换策略”的桌面操作方式。其最终常见发布版本为 0.20.39,项目已于 2023 年停止更新。

还需要澄清一点:Clash for Windows 并不是完整开源的图形客户端,不能因为名称里包含 Clash 就把它与原始开源内核视作同一个项目。如今继续使用旧安装包会面临新系统适配、内核能力和问题修复停滞等限制。新装环境更适合选择仍有维护记录、并明确说明所用内核的客户端。

一份订阅为何在不同客户端里表现不同

订阅能否导入只是第一关。客户端拿到订阅内容后,还要交给内核解析。即使两个界面都显示“Clash 配置”,底层内核版本、覆写逻辑、DNS 实现和流量接管方式不同,最终结果也可能不同。常见差异主要集中在以下四处。

配置字段与代理协议支持

基础字段如 mixed-port、proxies、proxy-groups 和 rules 兼容范围较广。
新协议参数、规则集合行为和高级 DNS 选项通常要求较新的 mihomo 内核。
客户端可能在订阅原文之外追加本地覆写,例如更换端口、启用局域网访问或插入 TUN 配置。
同名策略组可以由订阅生成,也可能被客户端脚本修改,排查时要区分远程原文与最终运行配置。

系统代理与 TUN 接管范围不同

系统代理一般把 HTTP 与 SOCKS 代理地址写入操作系统设置。常见本地混合端口是 127.0.0.1:7890,应用必须读取系统代理或手动指定该端口,流量才会进入内核。游戏、部分命令行程序和自行实现网络栈的应用可能绕过系统代理。

TUN 模式则通过虚拟网络设备接管更多 IP 流量。它更依赖系统权限、路由表、DNS 劫持与网络栈设置。两个客户端即使使用相同 mihomo 版本,只要一个成功安装服务组件、另一个没有获得权限,TUN 表现就会不同。判断问题时应先看日志里是否出现 TUN 设备创建成功,再检查规则命中,不要把权限失败误判为节点失效。

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上面的 7890 是代理入口,9090 是外部控制接口,二者用途不同。外部控制接口用于客户端界面查询连接和切换策略,不应被浏览器当作 HTTP 代理端口。若客户端已经自动生成控制密钥,应保留其生成值,避免界面与内核失去连接。

DNS 策略会改变规则匹配结果

Clash 系内核可根据域名、IP 地址和规则顺序决定去向。在 fake-ip 模式下,内核先给应用返回保留地址,再维护域名映射以完成后续规则匹配。若客户端修改了 enhanced-mode、nameserver 或 fake-ip-filter,相同规则也可能呈现不同结果。

排查时可以在客户端的「日志」页面把级别调整为 info,分别访问一个国内域名、一个需要代理的域名和一个纯 IP 地址。连续观察至少 30 秒,确认三类请求分别命中预期策略。若域名规则正常而纯 IP 流量绕过,优先检查 TUN 或系统代理接管范围;若全部进入兜底策略,再检查规则顺序与 DNS 映射。

如何判断一个项目当前是否值得使用

项目名称只能说明来源,不能直接代表当前状态。选择客户端时应同时检查发布记录、内核来源、系统适配和配置兼容。一个界面仍能打开,不等于它能妥善处理当前订阅中的所有字段。

查看最近发布记录。确认正式版本的发布日期、版本说明和支持系统,不要只看仓库是否还能访问。
确认内核名称与版本。优先选择能在「设置」→「关于」或「设置」→「Clash 设置」中明确展示 mihomo 版本的客户端。
核对操作系统架构。Windows 常见为 x64 与 ARM64,macOS 需要区分 Apple Silicon 与 Intel,Linux 还要确认 AppImage、deb、rpm 或命令行部署方式。
检查权限机制。需要 TUN 时,确认客户端是否提供服务模式、管理员权限说明或 macOS 网络扩展授权流程。
验证订阅要求。如果配置提供方注明需要 mihomo、Meta 或特定协议支持,就不要选用只集成旧版原始 Clash 的客户端。
保留可回退配置。更新客户端或内核前导出当前可用配置,记录系统代理端口、覆写项与 DNS 设置。

从旧客户端迁移到 mihomo 客户端

从 Clash for Windows、旧 ClashX 或早期 Verge 迁移时,最稳妥的方式是把订阅和本地设置分开处理。先在新客户端导入原始订阅,确认基础代理可用,再逐项恢复覆写、TUN、局域网访问和自定义规则。直接复制整个旧配置目录,容易把缓存、旧内核路径和已失效的控制器设置一起带过去。

迁移前记录五项参数

当前订阅地址及更新时间,同时确认订阅仍可正常刷新。
代理入口端口,常见为混合端口 7890,也可能分别使用 HTTP 7890 与 SOCKS 7891。
当前模式是 Rule、Global 还是 Direct,以及默认策略组选择。
是否启用 TUN、局域网连接、IPv6 和自定义 DNS。
本地增加的规则、脚本或配置覆写,这些内容通常不会包含在远程订阅中。

按三轮测试确认迁移结果

第一轮只开系统代理。关闭 TUN,选择 Rule 模式,分别打开国内站点与需要代理的站点,确认日志出现对应规则和策略组。
第二轮测试订阅刷新。手动更新一次配置,等待页面显示更新时间,再确认策略组选择没有被意外重置。
第三轮启用 TUN。启动服务模式或完成系统授权,测试一个不读取系统代理的命令行程序。可使用 curl --connect-timeout 10 https://example.com 限定 10 秒连接超时,并对照客户端连接列表。

若第一轮成功而第三轮失败,问题通常位于 TUN 权限、路由或 DNS,不必重新更换订阅。若配置导入阶段已经报错,则应查看首条解析错误,确认具体字段是否要求 mihomo。若只有个别节点失败,再对比协议参数与服务端状态。

用一张关系图记住整个生态

Clash 生态并不是“一个软件换了很多名字”,而是一组共享配置理念、又由不同团队维护的项目。原始 Clash 是基础内核;Clash.Meta 在其配置模型上扩展能力;Clash.Meta 后续以 mihomo 名称持续开发。Clash Verge Rev、ClashX 等项目位于图形客户端层,通过集成内核完成实际代理工作。订阅则位于配置层,可以在兼容客户端之间迁移。

订阅与 YAML 配置
        │
        ▼
图形客户端
Clash Verge Rev / ClashX / 其他客户端
        │
        ▼
代理内核
mihomo（原 Clash.Meta）
        │
        ▼
规则匹配 / DNS / 系统代理 / TUN / 连接转发

选择时可以把问题压缩成三个:客户端是否仍在维护,它集成什么内核,当前订阅是否依赖该内核的扩展能力。回答这三个问题后,名称相似带来的混乱会明显减少。对于新安装环境,优先关注仍有发布记录、明确集成 mihomo、并能适配当前操作系统权限机制的客户端;对于已有稳定环境,则应先记录配置与端口,再分阶段迁移。