Clash、mihomo 与各家 GUI 客户端的关系:开源生态脉络梳理

先区分内核、图形界面与订阅

先把一个代理客户端拆成几层，再比较软件名称。内核负责读取配置、解析域名、匹配规则并转发连接；GUI 是图形用户界面，负责显示按钮、管理订阅、选择策略组和保存设置。两者通常打包在同一个安装包里，但不是同一个项目。

把订阅放在第三层理解。订阅是服务提供方交付配置或节点信息的方式，不是内核，也不是客户端。安装 Clash Verge Rev 不会自动获得可用节点；拥有一条订阅，也不代表它能被所有写着“Clash”的软件直接读取。

沿着“应用 → 本地代理入口 → 内核 → 规则选中的出口”理解流量。假设客户端把混合端口设为 7890，浏览器向 127.0.0.1:7890 发送代理请求，之后才由内核决定直连还是使用节点。这里的端口是示例，不是每个客户端都固定使用的默认值。

梳理 Clash、Clash Premium 与 mihomo 的脉络

原版 Clash：规则代理内核的起点

先认清原版项目。通常所说的原版 Clash，指 Dreamacro 发起的 Go 语言代理内核。它建立了许多用户熟悉的配置结构，例如 proxies、proxy-groups 和 rules。Clash for Windows、ClashX 等名称里带 Clash 的桌面软件，则属于围绕内核提供操作界面的客户端。

把原版开源内核与 Clash Premium 分开看。Premium 是当时另行发布的闭源内核分支，能力集合与开源版本不同。旧教程写“需要 Premium”时，描述的是当时的内核条件，不能据此判断今天安装的 mihomo 是否支持同一字段。到 2023 年 11 月，原版 Clash 项目及若干相关客户端的公开维护出现重大变化；后续选型应查看各自仓库，而不是把它们当成一个统一发布的软件。

Clash Meta：从 Clash 分支继续扩展

再看 Clash Meta。它从 Clash 的代码基础发展而来，扩展了协议支持、DNS、规则与 TUN 等能力。TUN 是虚拟网络接口，可让内核通过系统路由接收流量；它与浏览器读取的系统代理不是同一种接管方式。

理解更名关系。Clash Meta 后来更名为 mihomo，当前项目位于 MetaCubeX 组织下。旧配置说明、进程名称或客户端界面里仍可能保留 Meta 字样，因此看到“Meta 内核”不必立即判断为另一个完全不同的项目。应继续核对实际内核版本和发布来源。

不要把相似名称当作统一的官方关系

逐个核对维护者和仓库。Clash Verge Rev、Clash Nyanpasu、ClashX Meta 等项目有各自的开发与发布节奏。它们使用同一类内核，并不意味着由同一个团队发布，也不意味着一个项目的更新说明适用于另一个项目。

对照各平台 GUI 客户端与内核关系

先看下面的关系表，再核对具体安装版本。表格描述项目常见的内核路线，不保证历史版本、第三方重打包或所有分支完全一致。能否使用某项功能，最终取决于本机实际运行的内核与 GUI 集成方式。

注意名称后缀。例如 FlClash 与 FlClashs 不能只因拼写接近就认定为同一个发布源；带 Meta、Rev 或其他后缀的客户端，也要分别核对项目主页、发布记录和内核说明。本站提供的平台入口范围，亦不等于上游项目的完整平台支持列表。

单独判断 iOS 客户端。iOS 上的网络接管依赖系统提供的网络扩展机制，应用可能支持导入 Clash 格式配置，却不一定直接使用 mihomo。对 Clash Plus 等具体产品，应以对应平台发行版的技术说明为准；支持某种订阅格式，不足以证明内核相同。

判断 Clash 订阅能否迁移到 mihomo

先检查订阅内容，再尝试导入。订阅链接可能返回完整 YAML 配置，也可能返回节点列表，甚至返回面向其他软件的格式。客户端提示“解析失败”，不一定是节点失效，也可能是把不匹配的内容交给了配置解析器。

依次检查四类兼容性

1. 检查顶层结构。完整 Clash 风格配置通常包含节点、策略组和规则等字段。只有节点列表的内容，往往需要 GUI 的订阅管理或配置合并功能才能使用。
2. 检查协议与字段。新内核支持的节点类型、传输参数或 DNS 字段，旧内核未必认识。出现 unsupported proxy type 一类提示时，先核对内核版本与对应文档。
3. 检查外部资源。proxy-providers 是外部节点提供器，rule-providers 是外部规则提供器。主配置能下载，不代表这些外部地址也可访问。
4. 检查本地覆盖。GUI 可能覆盖端口、DNS、控制接口与 TUN 参数。订阅文件里的值，不一定等于最终传给内核的运行配置。

把兼容理解为有方向的关系。mihomo 通常可以承接许多 Clash 风格配置，但使用 mihomo 扩展字段的配置，不能保证交给旧版 Clash 后仍然工作。即使两个客户端都使用 mihomo，也可能因为捆绑的版本不同而出现差异。

在本机确认实际内核与配置

先记录 GUI 版本，再记录内核版本。两者可能分别更新。例如界面已经更新，但内核下载失败时仍可能使用旧文件；反过来，替换内核也不会自动改变 GUI 的设置选项。

从界面与启动日志交叉确认

• 打开客户端的「关于」或版本信息区域，记录应用名称与完整版本号。不同客户端菜单名称不同，不要照搬另一个客户端的菜单路径。
• 查看内核管理区域，确认选中的内核名称与版本。如果能切换多个内核，以当前启用项为准。
• 重启一次内核，检查启动日志中的版本信息、配置错误与监听端口。不要只看窗口是否打开。
• 需要向社区求助时，同时写明系统版本、处理器架构、GUI 版本和内核版本，并注明是否开启系统代理或 TUN。

如果直接运行 mihomo，可在其程序所在目录执行下面的命令。示例假设当前目录已经有一份自己的 config.yaml；Windows 使用 PowerShell，macOS 和 Linux 使用终端。配置测试成功只表示通过相应检查，不代表每个节点都能连接。

# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

# macOS / Linux
./mihomo -v
./mihomo -t -f ./config.yaml

优先通过 GUI 提供的配置检查功能测试最终运行配置。部分客户端会合并订阅、覆写与脚本结果，直接测试订阅原文件可能遗漏合并阶段的问题。不要在 GUI 已经运行内核时，额外启动第二个监听相同端口的实例。

区分代理端口与控制接口

核对端口的用途。例如 mixed-port: 7890 表示 HTTP 与 SOCKS 混合代理入口，而 external-controller: 127.0.0.1:9090 表示供界面或面板调用的控制接口。它们只是示例值；把浏览器代理指向控制接口，并不能正常转发网页请求。

按设备与维护需求选择客户端

先选系统原生支持的平台，再选界面习惯。不要为了一个熟悉的名字，长期停留在不再适配当前系统的旧发行版。开源与免费是项目属性，实际使用仍要检查近期发行记录、问题反馈和安装包来源。

1. 确认系统与架构。Windows 设备先区分 x64 与 ARM64；macOS 先区分 Apple Silicon 与 Intel。Linux 还要核对发行版的包格式，例如 DEB 或 RPM。
2. 确认配置所需能力。订阅使用了哪些协议、规则提供器或 DNS 参数，就对照内核文档核实这些能力，而不是单看界面截图。
3. 确认接管方式。普通浏览器需求可先使用系统代理；需要覆盖不读取系统代理的程序时，再评估 TUN，以及客户端是否提供可靠的权限和服务管理。
4. 确认配置可备份。保存订阅入口、覆写规则与必要的本地设置。升级前记录内核版本，出现问题才有明确的回退依据。

迁移时先退出旧客户端，再导入订阅并逐项启用功能。让两个客户端同时改写系统代理、DNS 或路由，会使故障来源难以判断。建议按“配置通过检查 → 系统代理可用 → 规则分流正常 → 按需启用 TUN”的顺序验证。

遇到“同一订阅在旧软件可用、新软件不可用”，先比较实际运行配置与日志。不要立即复制旧客户端的整个数据目录，因为缓存结构、服务配置和文件路径可能不同。需要基础操作时，可查看使用文档；需要按症状定位时，可进入问题诊断。

常见问题：名称相近时如何判断

mihomo 是 Clash 的新版官方客户端吗？

把它视为独立维护的内核项目更准确。mihomo 延续了 Clash Meta 的开发路线，不是一个带完整桌面窗口的统一官方客户端。选择 GUI 后，仍需确认它捆绑或调用的内核。

使用相同内核，连接表现就一定相同吗？

先比较配置与系统环境。DNS、分流规则、节点选择、TUN 路由以及本地防火墙都会影响结果。相同内核版本只是减少一个变量，不能抵消这些差异；也不能仅凭客户端名称推断速度。

能否把任意客户端里的内核直接替换成 mihomo？

先查客户端是否明确支持自定义内核。GUI 可能依赖特定的控制接口、启动参数与文件布局，移动端还涉及内核集成和应用签名。没有明确支持时，不要仅靠改文件名替换，优先选择已经适配 mihomo 的维护中客户端。

新手需要同时安装多个客户端吗？

先用一个完成导入、选组与连通性验证。记录 GUI、内核、订阅和接管方式这四项，就足以描述大部分基础环境。确有对照需求时再安装第二个，并确保同一时间只有一个客户端管理系统代理或 TUN。