生态选型 预计阅读 11 分钟

Clash、Meta 与 mihomo 是什么关系:开源客户端项目谱系梳理

按时间线梳理 Clash 原版内核、Meta 分支与 mihomo 的演进关系,并整理 FlClash、Clash Verge 等图形客户端分别基于哪个内核、适用于哪些平台。

先区分内核、图形客户端与订阅配置

搜索“Clash 安卓版”时，结果里常会同时出现 Clash Meta、mihomo、FlClash 和 Clash Verge Rev。这些名称不在同一层：有的是处理连接的内核，有的是提供按钮和设置页的客户端，还有的是历史分支名。把它们当成同一个软件的几个皮肤，容易选错安装包，也容易误判配置兼容性。

层级负责的工作常见名称或内容
代理内核解析配置、执行规则、处理 DNS、建立出站连接Clash、Clash Meta、mihomo
图形客户端安装与更新配置、展示策略组、调用系统网络权限FlClash、Clash Verge Rev、Clash Meta for Android
配置与订阅提供节点参数、策略组、规则及其他运行设置YAML 配置、远程配置地址、规则集合

手机用户通常安装图形客户端，而不是直接运行一个内核可执行文件。客户端可能把内核打包进应用，也可能允许单独更新内核。因此，应用版本与内核版本是两套信息；只看到客户端名称，不能确定它支持哪一种协议或哪一个新配置字段。

Clash 到 Meta，再到 mihomo 的演进时间线

原版 Clash：规则代理与配置结构的起点

Dreamacro 开发的 Clash 是以 Go 编写的规则代理内核。常见的 proxies、proxy-groups、rules 等配置结构，构成了许多后续客户端与订阅服务沿用的基础。内核本身并不等于安卓应用，也不自带手机上的订阅管理页面。

还要区分原版开源 Clash 与历史上的 Clash Premium。Premium 曾以独立二进制形式发布，部分增强功能并不属于原版开源内核。旧教程中提到“需要 Premium”的功能，不能直接套用到所有名字含 Clash 的客户端；阅读时必须确认教程所指的内核和年代。

Clash Meta：从兼容基础上继续扩展

MetaCubeX 社区维护的 Clash Meta 从 Clash 衍生，继续发展协议支持、DNS、规则与 TUN 等能力。它保留了大量熟悉的配置结构，但也增加了原版内核无法识别的参数。因此，“是 Clash 格式”只能说明大体结构相近，不保证任何历史内核都能加载。

例如，订阅提供方标注“Meta / mihomo”时，可能使用 type: hysteria2 等较新的出站类型。把这种配置交给旧内核，可能在解析阶段就提示不支持的代理类型。此时调整节点排序没有作用，应先检查目标客户端实际集成的内核及其版本。

2023 年前后的维护变化与后续命名

2023 年 11 月前后，原版 Clash 及多个相关客户端的公开维护状态发生变化。原版仓库的可用性、桌面客户端的归档、安卓项目停止维护，是不同项目各自的事件，不能合并理解成“所有 Clash 软件同时停用”。已经安装的软件可能仍能运行，但后续系统适配和新协议支持需要另行判断。

到 2024 年初，Meta 分支采用了 mihomo 名称，项目仓库使用 MetaCubeX/mihomo。这属于同一发展脉络中的更名与持续演进，不是两套互不相干的内核。配置说明、旧应用标题或日志仍可能保留 Meta 字样，因此两种名称至今会在同一条排查链路中出现。

常见图形客户端分别使用什么内核

下面按项目通常采用的技术路线整理，适合用于理解谱系，而不是代替发布说明。第三方重新打包、开发版和历史版本可能采用不同组合。实际安装前，以项目发布页和应用“关于”中的信息为准。

项目内核关系主要平台与识别要点
FlClash基于 mihomo 的图形客户端Android、Windows、macOS、Linux；使用 Flutter 构建界面
Clash Meta for Android沿着 Clash for Android 界面路线接入 Meta / mihomo 内核Android；不能仅凭与旧版相似的界面判断内核
Clash Verge Rev基于 mihomo 的桌面客户端Windows、macOS、Linux；属于 Clash Verge 的后续分支项目
原版 Clash Verge历史发行曾提供 Clash / Clash Meta 内核选择桌面平台；与 Rev 是不同项目，原项目已归档
原版 Clash for Android历史发行使用 Clash 系内核，须按具体发行确认Android；原项目已停止维护，不能视为当前 mihomo 客户端

FlClash 与 Clash Verge Rev 不是手机、电脑两个版本号

两者都可以使用 mihomo，但界面、配置存储、系统代理设置和更新机制由各自客户端实现。把桌面端的“系统代理”开关位置照搬到安卓，往往找不到对应菜单。安卓通常依靠系统 VPN 接口接管流量，桌面端则可能分别提供系统代理和 TUN 入口。

安卓名称相近，不代表能覆盖安装

Clash for Android 与 Clash Meta for Android 的名称相似，但应用包名、签名和数据目录可能不同。系统能否覆盖安装取决于包名与签名等条件，而不是图标或应用标题。换客户端前，先保存订阅地址、本地覆写和策略组选择记录，不要默认新应用会读取旧应用的数据。

iOS 要单独核实应用与配置格式

上表中的 FlClash、Clash Meta for Android 和 Clash Verge Rev，不能据此推导出可安装的 iOS 版本。iOS 客户端需要适配系统的 Network Extension 等能力，安装渠道也与安卓不同。某个 iOS 应用支持导入部分 Clash 配置，不表示它一定运行 mihomo，更不表示支持完整的 mihomo YAML 字段。

为 iPhone 选型时，先核实应用支持的协议、订阅格式、规则形式和安装方式，再判断能否复用现有订阅。Android 的 APK 不能安装到 iOS；桌面内核的可执行文件也不是 iPhone 安装包。可在客户端选型指南中按系统继续比较。

同一条订阅为什么会出现不同的导入结果

完整配置与节点列表不是一回事

完整 YAML 配置可以同时包含节点、策略组、DNS、规则和监听端口。只含节点的订阅则可能需要客户端模板补齐其他部分。如果一个应用负责自动生成策略组，另一个应用要求导入完整配置，两者即使使用相同内核，也不一定接受完全相同的输入。

订阅服务还可能根据导出选项或请求特征返回不同内容。因此，比较时应确认选择的是“Clash”“Clash Meta / mihomo”还是客户端专用格式，并核对导入后的实际配置。订阅地址常带访问令牌，排查截图中应遮住令牌及节点凭据。

配置能解析，不等于功能已完整启用

下面是便于观察配置层级的片段，不是可直接替代订阅的完整配置。7890 是示例混合代理端口，9090 是示例控制接口端口；客户端可能覆盖这些设置，也可能使用其他端口。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

mixed-port 接收本地 HTTP / SOCKS 代理请求，external-controller 用于管理接口，两者不是同一个用途。手机应用通过 VPN 接口接管设备流量时，通常不需要用户给每个应用手填 7890。也不要为了解决连接问题，把控制接口随意改为面向整个局域网监听。

手机端选型：按维护、兼容性和系统集成检查

选型时先看手机系统，再看订阅要求，最后看操作习惯。应用名称中是否含“Clash”并不是充分条件。对依赖较新协议的配置，内核版本信息比图标相似度更有参考价值；对长期后台运行的设备，系统适配和日志入口同样重要。

  1. 确认平台与安装渠道。安卓先区分 APK 的设备架构；iOS 先确认当前可用的安装方式。不要把桌面客户端下载页当作手机入口。
  2. 查看应用版本与内核版本。在应用提供的“关于”“内核”或启动日志中分别记录两者。菜单名称由客户端决定，没有适用于所有应用的统一路径。
  3. 对照订阅格式。提供方明确要求 Meta / mihomo 时，优先选择说明中明确采用该内核的客户端，并确认所需特性对应的最低版本。
  4. 检查日常操作入口。订阅更新、策略组选择、运行日志和本地覆写应能方便找到。只会切换节点，不足以完成后续故障排查。
  5. 检查系统集成。安卓确认 VPN 授权，并按实际需要调整电池优化、后台活动或自启动设置；这些设置的名称取决于手机厂商。

更新频繁不等于每个版本都适合立即替换。升级前阅读发布说明，保存可恢复的配置，尤其留意 DNS、TUN、规则语法和配置迁移的变化。长期停止维护的客户端即使暂时可用，也应评估新系统适配与安全修复的缺口。

更换客户端前的迁移检查清单

同属 mihomo 生态只能降低部分配置迁移成本，不能保证应用数据直接互通。稳妥做法是先在新客户端完成独立验证，再移除旧客户端的数据。不要让两个需要系统 VPN 接口的应用同时争用连接。

  1. 保存输入。记录订阅来源、更新方式、本地规则、覆写文件以及手动指定的 DNS 设置。仅复制远程订阅，通常不会带走本地修改。
  2. 先保持默认。在新客户端导入配置，检查日志是否出现未知字段、代理类型不支持或策略组引用不存在等错误。
  3. 核对分流。切到规则模式，确认策略组指向预期出站。规则从上到下匹配，末尾 MATCH 的目标尤其需要检查。
  4. 验证网络变化。分别测试 Wi-Fi 与移动数据，并观察切网、锁屏后能否恢复。某次连通只代表当时的链路可用。
  5. 再迁移覆写。把本地改动逐项恢复，每次只改一类设置，避免同时替换 DNS、规则和 TUN 参数后无法定位问题。

如果“旧应用正常，新应用不通”，建议依次检查配置解析、策略组选择、DNS 日志、VPN 权限与后台限制，而不是直接认定 mihomo 与 Clash 配置完全不兼容。有关 DNS 与规则字段，可继续查阅技术参考中的 DNS 说明。

项目名称常见问题

Clash Meta 和 mihomo 需要安装两份吗？

通常不需要。两者指向同一分支的发展脉络，手机用户安装的是集成相应内核的客户端。只有在明确比较不同客户端时才需要分别安装，日常使用应避免多个 VPN 客户端同时启动。

Clash Verge Rev 能不能作为安卓 Clash 使用？

Clash Verge Rev 是桌面项目，面向 Windows、macOS 和 Linux。安卓应选择明确提供 Android 发行的客户端，例如 FlClash 或相应安卓项目；相同内核不代表安装包可以跨系统使用。

订阅写着 Clash，就一定兼容所有客户端吗？

不一定。还要看返回的是完整配置还是节点列表、是否包含 Meta / mihomo 扩展，以及客户端内置内核的版本。遇到导入错误时，保留去除凭据后的报错信息，比反复更换同一订阅地址更有效。

更换 mihomo 客户端后，原来的规则还能保留吗？

内核支持的规则通常可以迁移，但客户端覆写格式和合并顺序不一定相同。迁移后需确认规则实际写入运行配置，并检查引用的策略组名称是否仍然存在。

理解这条谱系后，判断顺序就清楚了：先确认操作系统和客户端，再确认内核及版本，最后核对订阅与系统权限。Clash、Meta 和 mihomo 的关系解释了配置为何相似；具体客户端的实现，则决定手机上的安装、更新和后台运行体验。

下载ClashAndroid / iOS 客户端