mihomo、Clash Meta 与各图形客户端是什么关系:开源生态谱系梳理

先分三层：代理内核、管理界面与系统接入

mihomo 是代理内核，Clash Meta 是它沿用过的项目名称；Clash Verge Rev 等客户端则把内核、图形界面和系统集成功能组合成可安装的产品。因此，“使用 Clash”并不能准确说明运行的是哪一个内核，也不能推断具体支持哪些协议、配置字段或系统功能。

排查问题时，应先确认问题发生在哪一层。节点协议无法识别，通常需要检查内核能力和配置格式；订阅按钮报错，可能发生在客户端的下载或解析阶段；浏览器能访问而其他应用不能访问，则还要检查系统代理、虚拟网卡与路由设置。

名称演变：Clash、Clash.Meta 与 mihomo

原版 Clash：配置体系与规则引擎的起点

原版 Clash 建立了这类工具常见的配置结构：通过 proxies 描述代理节点，通过 proxy-groups 组织策略，通过 rules 决定连接去向。许多后来出现的客户端沿用了这套 YAML 配置习惯，因此界面不同的产品之间通常存在一部分配置交集。

还要区分原版开源内核与历史上的 Clash Premium。Premium 曾作为另一条发布线提供部分进阶能力，不能把它的功能清单直接视作原版开源内核的功能清单。原项目在 2023 年 11 月停止公开维护后，旧软件仍可能启动，但这不代表它能持续兼容后续出现的节点协议或新配置字段。

Clash.Meta：从兼容基础上扩展能力

Clash.Meta 是从 Clash 生态发展出的分支，在配置兼容基础上扩展协议支持、DNS 与路由能力。早期文档、订阅选项和客户端菜单里常出现“Meta 内核”字样，通常指向这条项目线，而不是一个独立的图形客户端。

mihomo：Meta 项目的后续名称

Clash.Meta 后来更名为 mihomo，由 MetaCubeX 社区持续开发。因此，“Clash Meta 与 mihomo 哪个更好”通常不是在比较两个平行的新项目，而是在混用历史名称与后续名称。旧文件名、兼容字段或日志中保留 Meta 字样，也不必然说明内核停留在更名前。

Clash 原版开源内核
└─ Clash.Meta 分支
   └─ mihomo（后续项目名称）

图形客户端、移动客户端
└─ 集成某条内核发布线，并提供各自的界面与系统接入

这张图只表达内核项目的演变与客户端的集成关系，不表示所有名称带 Clash 的软件都来自同一个维护团队，也不表示各项目共享同一份开源许可证。确认项目身份时，应查看仓库、发布说明与许可证文件。

桌面客户端：哪些基于 mihomo，哪些属于历史分支

桌面客户端通常同时承担“管理配置”和“启动内核”两项工作。下面列出常见项目的技术定位；实际安装包包含的内核版本，仍应以客户端显示信息与发布说明为准。

其中，Clash Verge Rev 是独立维护的后续项目，并非只给原 Clash Verge 更换了一个版本号。迁移时应重新检查服务安装、配置目录与开机启动项，而不是假定旧客户端的系统集成会自动继承。

还应留意相近拼写。本站下载列表中的 FlClashs 与上表提到的上游 FlClash，不能只因名称相近就视为同一发布渠道。遇到衍生客户端，应分别核对其源代码仓库、所集成的内核和安装包来源。其他客户端也适用同样的判断方法。

移动端：Android VPN 服务与 iOS 网络扩展

Android：Clash for Android 与 Meta 分支需分开看

原版 Clash for Android 已停止维护。名称中带 Meta 的 Android 分支属于另一条维护线，不能用原版的版本记录判断其更新状态。FlClash 等跨平台客户端则采用不同的界面实现，但同样可以在 Android 上集成 mihomo。

Android 客户端通常通过系统 VpnService 接入设备流量。首次启用时出现的 VPN 授权，是允许客户端创建本地虚拟网络接口，不表示系统自动连接了某家远程 VPN 服务。最终连接到哪里，仍由节点、代理组和规则决定。

是否支持按应用分流、后台常驻以及局域网共享，还取决于客户端实现和系统限制。手机端即使与桌面端使用同一份订阅，也需要单独检查应用排除列表、电池优化策略和 DNS 设置。

iOS：界面相似不能证明内核相同

iOS 客户端一般需要借助 Network Extension 等系统机制处理网络流量，并受到扩展运行环境的限制。支持导入某类 Clash 订阅，只能说明客户端接受该格式或具备转换能力，不能直接证明它完整运行了相同版本的 mihomo。

选用 iOS 产品时，应检查其公开文档是否明确说明内核来源、支持的协议和配置字段。尤其是脚本、规则集、DNS 和 TUN 相关选项，不应直接照搬桌面教程中的菜单路径。

配置兼容边界：订阅、规则与界面覆写

订阅地址不等于最终运行配置

订阅返回的内容可能是完整 YAML，也可能只是节点列表，或者是需要客户端转换的其他格式。完整配置通常包含 proxies、proxy-groups 和 rules；节点型 provider 则通常只提供节点，由主配置定义代理组和规则。

图形客户端还可能把本地覆写、脚本处理和界面设置合并到订阅内容中。因此，排查“同一订阅在两个客户端结果不同”时，应比较最终交给内核的配置，而不只是比较订阅原文。迁移时先导入基础订阅，再逐项恢复覆写，更容易定位差异。

规则语法相似，也要检查策略名称

下面是说明规则顺序的片段，不是完整的可运行配置。它要求代理组中已经存在名为 PROXY 的策略；这里的 PROXY 是自定义名称，不是无需定义就能使用的通用内置出口。

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

规则按顺序匹配，末尾 MATCH 用于接住未被前面规则命中的连接。若迁移后把代理组改名为“节点选择”，规则里仍引用 PROXY，配置就可能无法通过检查。类似地，RULE-SET 引用的规则集名称也必须在 rule-providers 中存在。

TUN 与 Fake-IP 是不同维度

TUN 解决的是如何把流量送进内核；Fake-IP 是 DNS 处理模式，通过虚拟地址映射帮助恢复域名信息。二者经常一起使用，但并不是同一个开关。启用 TUN 不会自动修复错误的代理组，也不能保证所有 DNS 请求都按预期进入内核。

配置中的 tun、dns、协议专属字段及规则集格式，都可能存在版本要求。新内核接受的字段，旧 Clash 或旧 Premium 未必认识。出现未知字段或不支持的代理类型时，应先检查版本要求，而不是通过删掉报错字段来假装迁移成功。

确认当前内核：版本、进程与本地控制接口

最可靠的记录是“客户端名称与版本＋实际运行内核版本＋最终配置”。不同客户端的菜单位置会随版本变化，可先从“关于”、内核管理界面或启动日志中查找完整版本字符串；反馈问题时保留原始字符串，不要只写“最新版”。

1. 检查运行日志：关闭连接后重新启动内核，观察启动信息，确认内核名称及配置加载结果。
2. 检查实际二进制：对确认来源的 mihomo 文件运行 mihomo -v；使用 mihomo -t -f config.yaml 检查指定配置。命令行检测的文件必须与客户端实际启动的内核一致。
3. 检查控制接口：若已启用本地 REST API，可以查询 /version；控制端口和代理端口不是同一个用途。

以下采用明确的演示配置：混合代理端口为 7890，控制接口为 127.0.0.1:9090。这些值不是所有客户端的固定默认值；实际检查应读取运行配置。

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "local-demo-token-change-before-use"

对应的本机查询命令如下。示例令牌必须先替换为自己设置的值，不要把实际令牌贴到公开反馈中。

curl --header "Authorization: Bearer local-demo-token-change-before-use" \
  http://127.0.0.1:9090/version

Windows PowerShell 中可使用 curl.exe，并把命令写成一行。连接被拒绝通常意味着端口不对或接口未监听；返回 401 则应检查认证令牌。不要为了获取版本信息把控制接口改为监听所有网卡，控制接口具备配置和连接管理能力，应限制访问范围。

选型与迁移清单：先确认能力，再调整接入方式

选择客户端时，可以按下面的顺序决策。这样能把“界面偏好”与“运行能力”分开，也能避免一次改变过多设置后难以回溯。

1. 确认平台和架构：Windows、macOS、Linux、Android、iOS 的权限模型不同，Apple 芯片与 Intel 安装包也不能只按文件大小选择。
2. 确认内核需求：核对订阅中的协议类型、provider 格式和 DNS 字段是否被目标内核版本支持。
3. 备份配置来源：分别保存订阅地址、本地规则、覆写与脚本；不要把含凭据的配置上传到公开位置。
4. 只运行一个接管流量的客户端：迁移时先关闭旧客户端的系统代理或 VPN/TUN，避免端口冲突和路由竞争。
5. 先测基础链路：导入订阅、选择策略组，再用浏览器发起请求，在连接列表中核对命中规则与实际出口。
6. 最后恢复高级功能：逐项启用 TUN、DNS 覆写、应用分流与开机启动，每次更改后检查日志。

归纳起来，Clash 是这套配置生态的重要起点，Clash.Meta 与 mihomo 是同一项目线上的历史名称与后续名称，各图形客户端则负责把内核接入不同操作系统。理解这三层关系后，就能更准确地判断：问题需要更新内核、修改配置，还是调整客户端的系统权限。

需要继续核对参数时，可查阅使用手册；不熟悉策略组、Fake-IP 或 TUN 的概念，可先阅读术语手册。