生态选型 预计阅读 12 分钟

Clash 开源生态图谱:原版、Meta、mihomo 与各客户端的关系一次讲清

从原版 Clash 内核讲起,梳理 Meta 分支更名 mihomo 的来龙去脉,以及 FlClash、Verge、ClashX 等客户端分别基于哪个内核、维护状态如何。

先分清内核、客户端与配置文件

Clash 生态最常见的误解，是把所有带有 Clash 名称的软件视为同一个项目。实际上，它们至少分为三层：负责网络转发的内核、提供图形界面的客户端，以及由订阅服务或用户维护的 YAML 配置。三层可以组合，但维护者、版本号和兼容范围并不相同。

内核负责真正的流量处理

内核读取配置文件，监听本地代理端口，执行 DNS、规则匹配、策略组选择和出站连接。经典配置常见的 HTTP 与 SOCKS 混合端口是 7890，外部控制接口常设为 127.0.0.1:9090。系统代理、TUN 虚拟网卡和规则分流最终都要落到内核执行。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: change-this-secret

客户端是内核的操作界面

FlClash、Clash Verge Rev、ClashX 等名称通常指图形客户端。客户端负责导入订阅、启动或停止内核、修改系统代理、展示连接记录，也可能管理系统服务与 TUN 权限。客户端自身能否启动，不等于内核已经正常监听；判断运行状态时，应同时检查内核日志、端口占用和控制接口。

订阅不是客户端安装包

订阅链接返回的通常是节点与策略配置。它不会安装内核，也不会自动赋予系统网络权限。同一份基础订阅可以导入不同客户端，但如果配置使用了 rule-providers、sniffer、Hysteria2、TUIC 或 mihomo 特有 DNS 字段，经典 Clash 内核可能无法解析。

原版 Clash：生态的配置与 API 基础

原版 Clash 由 Dreamacro 发起，以 Go 编写。它建立了今天仍被大量客户端沿用的基本模型：代理节点放入 proxies，策略组放入 proxy-groups，流量按照 rules 从上到下匹配，并通过 RESTful 外部控制接口向图形界面提供状态、连接和策略切换能力。

经典字段至今仍是生态的共同语言，例如 mode: rule、mixed-port、dns.enable、external-controller。因此，即使正在使用 mihomo，配置文件看起来仍然很像原版 Clash。这是兼容延续，不代表两个内核处于同一维护线。

原版停止维护后的实际影响

原版项目在 2023 年停止公开维护，常见存档版本为 v1.18.0。停止维护意味着新协议、规则能力、操作系统网络栈变化和安全修复不再持续进入原版。已经固化在旧设备中的经典配置可能继续运行，但不适合作为新部署的默认选择。

  • 配置层：基础代理、策略组和域名规则仍有很高的迁移价值。
  • 内核层：不再期待原版获得新的协议支持或 TUN 改进。
  • 客户端层：仍写着 Clash 名称的软件，可能早已替换为 mihomo，也可能仍捆绑旧内核。
  • 订阅层：服务端生成配置时若启用 mihomo 扩展，导入经典内核可能直接报字段错误。

Clash.Meta 到 mihomo：一次更名与持续演进

Clash.Meta 最初是兼容 Clash 配置体系的增强分支。它保留了原版常用配置结构和控制接口，同时加入更多代理协议、规则集、DNS 行为、流量嗅探与 TUN 能力。原版停止维护后，Clash.Meta 成为大量新客户端采用的内核路线。

随后，Clash.Meta 更名为 mihomo，项目由 MetaCubeX 社区维护。更名主要影响项目名、二进制文件名、镜像名称和文档入口，并不意味着配置体系被整体推倒重来。旧资料里的“Meta 内核”和新资料里的“mihomo 内核”，通常指向同一条演进路线的不同阶段。

mihomo 相比经典内核增加了什么

  • 更多出站协议：除经典的 Shadowsocks、VMess、Trojan 等类型外，持续扩展 VLESS、TUIC、Hysteria2、WireGuard 等实现。
  • 规则集能力：rule-providers 可以从本地文件或远程地址加载规则集合，便于把大型域名与 IP 规则拆分更新。
  • TUN 改进：可通过虚拟网卡接管不遵循系统代理的软件，并针对不同平台使用适合的网络栈。
  • 流量嗅探：在条件允许时，从 TLS SNI 或 HTTP Host 还原目标域名，让仅获得目标 IP 的连接也有机会匹配域名规则。
  • DNS 扩展：提供 fake-ip、redir-host、按域名选择解析器、规则跟随与更细的 nameserver 策略。

这些能力不会因为安装了采用 mihomo 的客户端就自动生效。例如，TUN 仍需要系统权限与正确路由；嗅探需要配置 sniffer.enable: true；远程规则集需要有效的下载地址和更新间隔。内核提供能力，配置决定是否启用。

如何确认当前运行的是 mihomo

最直接的方法是查看客户端的“关于”“内核”或“版本”页面。若客户端未展示，可在已启用外部控制接口的前提下请求 /version。下面的命令对应控制端口 9090，并使用前文设置的控制密钥：

curl -H "Authorization: Bearer change-this-secret" \
  http://127.0.0.1:9090/version

返回内容通常包含版本字符串和实现标识。若接口连接被拒绝，先确认核心正在运行，并检查 external-controller 是否只绑定本机地址。若返回 401 Unauthorized，说明控制接口可达，但请求中的密钥不匹配。

FlClash、Verge、ClashX 分别位于哪一层

客户端之间最重要的差异，不只是界面风格，而是使用哪条内核维护线、如何管理系统代理与 TUN、配置是否能够原样迁移。下面按项目家族拆开说明。

FlClash：Flutter 客户端与 mihomo 内核

FlClash 是使用 Flutter 构建的多平台图形客户端，核心执行层采用 mihomo。它负责订阅管理、策略切换、连接查看、日志展示和系统代理等操作，协议解析与规则执行则由 mihomo 完成。因此，讨论 FlClash 是否支持某个代理协议时，应同时核对 FlClash 集成的内核版本以及该协议对应的配置字段。

FlClash 的跨平台界面有利于保持操作逻辑一致，但 Windows、macOS、Linux 与 Android 的权限模型仍不同。例如，桌面系统代理主要影响遵循代理设置的应用；TUN 模式则需要创建虚拟网络接口。Android 上还会通过系统 VPN 授权弹窗接管流量，不能把桌面端权限步骤直接套用到移动端。

Clash Verge 与 Clash Verge Rev：名称相近，维护线不同

原 Clash Verge 是一款桌面图形客户端，曾经广泛用于 Windows、macOS 与 Linux。原项目停止维护后，社区延续项目 Clash Verge Rev 成为新的维护分支。搜索“Verge 下载”时经常会同时看到旧版、复刻包和 Rev 版本，必须核对完整项目名、发布日期与内核信息。

Clash Verge Rev 采用 mihomo 路线，适合需要桌面托盘、系统代理、TUN、订阅管理和连接查看的用户。旧 Clash Verge 的配置数据可以作为迁移来源，但不应直接假设数据库、服务安装方式和应用设置完全兼容。迁移时更稳妥的做法是导出订阅地址和自建 YAML，再在新客户端中重新导入。

ClashX：经典 macOS 客户端家族

ClashX 是 macOS 上较早流行的菜单栏客户端，历史版本主要围绕经典 Clash 内核运行。它与原版 Clash 的配置结构关系紧密，但其主维护线已经停滞。继续使用旧 ClashX 时，基础 HTTP、SOCKS、常规策略组可能仍可工作，mihomo 新增字段和新协议则不能默认兼容。

ClashX Pro、ClashX.Meta 等相近名称也曾出现，但它们不是同一个仓库的连续版本。尤其是 ClashX.Meta，它体现的是把 macOS 图形界面与 Meta 内核结合的分支思路。看到“ClashX”三个字时，需要进一步确认具体分支、最后发布日期、CPU 架构和实际核心。

Clash for Windows：常见但已停止维护的桌面客户端

Clash for Windows 常缩写为 CFW，曾经覆盖 Windows、macOS 与 Linux。它是图形客户端，不等同于原版 Clash 内核项目，而且客户端本身并非整个 Clash 开源生态的统一上游。CFW 已在 2023 年停止维护，旧安装包中的界面和核心不会继续获得常规更新。

从 CFW 迁移时，重点保存的是订阅 URL、自建配置、覆写规则与策略偏好，不是复制整个应用目录。旧配置中的 parsers、脚本或客户端专属覆写功能，可能无法被另一款客户端直接识别，需要改写成目标客户端支持的覆写方式或标准 mihomo YAML。

其他仍常见的 mihomo 客户端

  • Clash Nyanpasu：面向桌面平台的图形客户端，采用 mihomo 内核路线，提供配置、代理和连接管理。
  • Mihomo Party：以 mihomo 为核心的桌面客户端，名称直接体现其内核关系。
  • OpenClash：面向 OpenWrt 的管理与集成方案，通过路由器侧服务运行 Clash.Meta 或 mihomo，并结合防火墙规则接管局域网流量。
  • 命令行 mihomo：不依赖图形客户端，可通过 YAML、系统服务和外部控制面板组成服务器或网关方案。

维护状态不能只看“还能打开”

一款客户端能够启动，只能说明当前安装包与当前系统暂时可以运行。判断维护状态应查看版本发布、提交活动、内核升级速度和系统适配记录。尤其在操作系统大版本更新后，TUN 驱动、网络扩展、系统服务权限和代码签名都可能变化。

四项检查比项目名称更可靠

  1. 检查最近发布：记录最新稳定版发布日期，而不是只看仓库最近一次文档修改。
  2. 检查内核版本：客户端更新不一定同步更新 mihomo；查看关于页面或核心日志中的实际版本。
  3. 检查系统适配：确认安装包支持当前 CPU 架构，例如 macOS 的 Apple Silicon 与 Intel、Windows 的 x64 与 arm64。
  4. 检查问题处理：观察安装失败、TUN 无法启动、订阅解析错误等问题是否仍有维护者处理。

截至本文日期 2026-07-28，原版 Clash、原 Clash Verge、ClashX 主线和 Clash for Windows 应按停止维护项目看待；mihomo 仍是活跃内核路线；FlClash、Clash Verge Rev 等客户端则属于围绕 mihomo 构建的独立项目。客户端维护状态可能随时间变化，安装前仍应以该项目最新正式发布记录为准。

配置迁移：兼容基础字段，不等于完全通用

从经典 Clash 客户端迁移到 mihomo 客户端通常较顺畅，因为基础节点、策略组和规则语法被延续。反方向迁移则更容易失败：经典内核无法识别 mihomo 后续增加的协议与字段。迁移前应先区分“标准基础配置”“内核扩展配置”和“客户端专属设置”。

通常可以直接迁移的内容

  • 订阅 URL 与本地 YAML 文件。
  • 常见 proxies、proxy-groups 和 rules。
  • DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等基础规则。
  • 常用端口、局域网访问开关和基础 DNS 地址。

需要重新核对的内容

  • 客户端专属覆写、脚本、配置合并与订阅预处理功能。
  • TUN 网络栈、自动路由、严格路由与接口名称。
  • GeoData 模式、规则集格式和远程资源更新地址。
  • fake-ip 过滤列表、DNS 分流与系统 hosts 行为。
  • VLESS、Reality、TUIC、Hysteria2 等扩展协议字段。

完成迁移后，可先保持 mode: rule，依次验证订阅更新、节点连通、DNS 解析、规则命中和系统代理。最后再开启 TUN，避免同时修改过多变量。日志中若出现 field not found、unsupported proxy type 或 YAML 解析错误，应先定位字段兼容性，而不是反复重装客户端。

选型结论：先选维护线，再选界面

新安装优先选择采用活跃 mihomo 内核、持续发布且明确支持当前系统的客户端。需要 Windows、macOS、Linux 或 Android 间保持相近操作逻辑时，可以考虑 FlClash；偏好桌面托盘与系统服务管理时，可比较 FlClash、Clash Verge Rev、Clash Nyanpasu 和 Mihomo Party；在 OpenWrt 路由器上集中接管局域网流量，则应评估 OpenClash 与命令行 mihomo。

旧客户端仍能运行时，也应先记录订阅地址、导出自建规则并确认当前端口。常见的 7890、7891 与 9090 可能被旧进程占用，导致新客户端核心启动失败。迁移期间只保留一个客户端接管系统代理或 TUN，可以减少代理环回和默认路由冲突。

整张生态图可以归纳为一条清晰关系：原版 Clash 建立配置与控制接口基础；Clash.Meta 在兼容基础上扩展能力；Clash.Meta 后续更名为 mihomo 并持续维护；FlClash、Clash Verge Rev 等项目是调用 mihomo 的图形客户端；ClashX、原 Clash Verge 与 CFW 则属于不同历史阶段的客户端项目。理解这几层之后，名称相似不再是选型障碍。

FlClash 下载入口 查看各平台客户端