mihomo 内核与 Clash Verge、FlClash 等图形客户端的关系梳理

先分三层：内核、图形客户端、配置文件

搜索“Clash 下载”时，结果里往往混着内核程序、桌面安装包和手机应用。它们不是同一种东西。先把三层关系拆开，后面的版本选择、配置报错和迁移问题就容易定位。

• 内核：负责接收连接、查询 DNS、匹配规则、建立出站连接。mihomo 属于这一层，可以不依赖图形界面独立运行。
• 图形客户端：负责订阅导入、节点选择、日志展示，以及调用系统代理、后台服务等平台功能。Clash Verge Rev、FlClash 属于这一层，通常随安装包提供可用内核。
• 配置文件：告诉内核监听哪个端口、使用哪些节点、按什么规则分流。客户端还可能在启动前对配置进行合并、覆写或生成。

例如，界面里的“系统代理”按钮通常修改操作系统的代理设置；mixed-port: 7890 则让内核提供一个 HTTP/SOCKS 混合代理入口。按钮打开了，但应用不遵循系统代理，流量仍可能不经过这个端口。两者不是同一个开关。

演进时间线：Clash → Clash Meta → mihomo

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

原版 Clash 是使用 Go 编写的规则代理程序，建立了这套生态中常见的 YAML 配置结构，例如 proxies、proxy-groups 和 rules。许多后续客户端沿用了这些概念，但沿用配置结构不等于来自同一个开发团队。

历史上还存在 Clash Premium。它是在原版生态中提供额外能力的闭源内核分支，不能与原版开源内核混为一谈。旧教程里的“需要 Premium”通常有特定时代背景，不能直接推导为今天仍应寻找旧版 Premium 程序。

Clash Meta：扩展分支，不是界面皮肤

Clash Meta 是从 Clash 发展出来的内核分支，扩展了协议支持、DNS 和规则处理等能力。旧配置、订阅服务和客户端设置中常见的“Meta 内核”，通常指向这条演进路线，而不是某个名为 Meta 的图形主题。

mihomo：延续 Meta 路线的项目名称

2023 年末前后，Clash 生态经历原项目仓库下线、客户端停更和社区接续。Clash Meta 后来更名为 mihomo，当前项目位于 MetaCubeX 组织下。因此，“Clash Meta 与 mihomo 有什么区别”的简短答案是：前者是这条内核路线的旧名称，后者是后续项目名称。

名称延续不代表二进制永远等价。几年前的 Meta 内核与新版本 mihomo，在字段、协议和默认行为上都可能不同。排障时要记录实际版本号，而不是只写“用的是 Meta”。同样，不能把 mihomo 称为原 Clash 团队发布的新版本。

客户端对应关系：Clash Verge 与 Verge Rev 要分开

下面按项目关系判断，不替任何具体安装包承诺内核版本。发行方可能更新内核、增加构建选项或调整平台支持，最终以所装版本的发布说明和运行信息为准。

名称相近，也要核对仓库与发行方

Clash Verge 与 Clash Verge Rev 不是可以随意省略后缀的同一个发行项目。安装包文件名、软件内部名称、项目仓库应对应起来。站点或发行包中出现 FlClash 的派生名称时，也应确认它是上游原版、重打包还是修改后的分支，不能只凭相似图标判断。

需要桌面和手机共用配置时，先检查内核功能交集，再比较界面习惯。平台选型可参考客户端对比；具体下载安装则进入下载页，不要为了沿用旧教程而固定在已停止维护的客户端上。

配置兼容：相同 YAML，不等于相同运行结果

协议与字段由实际运行的内核解释

YAML 只是数据格式。文件能被解析，不代表里面的节点协议和参数都受支持。例如，包含 type: hysteria2 的节点需要支持该协议的内核，不能因为客户端能导入 YAML，就认为旧版 Clash 或 Premium 一定可以连接。

基本字段也要看语义与组合。mode: rule 表示规则模式；规则按照顺序匹配，MATCH 通常用于末尾兜底。若客户端覆写把模式改成全局，原订阅中的规则即使保留，也不会按预期承担分流工作。

客户端可能生成另一份运行配置

订阅原文、客户端编辑器内容、实际交给内核的配置，可能是三份不同文件。覆写脚本、合并配置和界面开关都可能改变最终结果。发现“改了 YAML 没生效”，先查看客户端是否提供“运行配置”“当前配置”或配置目录入口；这些名称随客户端版本变化，不要照搬另一款软件的菜单。

下面是一段用于核对概念的 mihomo 配置片段，不是完整订阅。已有配置中如存在同名顶层字段，应修改原字段，不能把它直接重复粘贴到末尾。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: false

• 7890 是示例入口，不是所有客户端的固定端口。浏览器、终端和系统设置应使用实际监听端口。
• allow-lan: false 表示不主动开放局域网代理访问，不能替代系统防火墙配置。
• tun.enable: false 关闭此配置中的 TUN；客户端界面若有覆写，最终值仍需检查运行配置。
• 配置片段没有节点、策略组和规则，不能据此判断订阅是否可用。

许可协议：内核与界面分别检查

原版 Clash 的开源代码、mihomo、Clash Verge Rev 和 FlClash 均涉及 GPL-3.0 许可。这个共同点不意味着它们是同一个项目，也不意味着任意第三方构建都已经履行分发义务。具体适用条款应查看对应版本的 LICENSE 文件，包括是否允许采用后续许可版本等细节。

普通使用与再次分发，关注点不同

• 个人安装使用：通常不需要为了运行客户端而公开个人订阅、规则或节点密码。软件源码许可与个人配置内容不是同一件事。
• 修改并向他人分发：需要按适用许可提供相应源代码、许可文本和必要声明，不能只保留一个项目名称就认为处理完毕。
• 打包第三方组件：界面、内核、依赖库和平台组件应分别核对。闭源的历史 Clash Premium 不能因为被开源界面调用，就被自动视为 GPL 开源代码。

核对发行包时，实用顺序是：找到软件“关于”或项目说明里的源码地址，确认发行标签，再阅读该标签下的许可文件。品牌授权、商标使用和源码许可也不是同一项授权。涉及商业再分发，应结合实际打包方式进行合规审查。

迁移操作清单：先保持行为一致，再启用新功能

从旧 Clash 客户端迁移到 mihomo 客户端，不建议一次性更换订阅、打开 TUN、切换 DNS 模式并添加覆写。变量太多，出错后很难定位。按下面顺序走，通常更容易回退。

1. 记录原环境。保存客户端名称、客户端版本、内核名称与版本、系统版本，以及系统代理和 TUN 的开关状态。导出配置前确认文件是否包含订阅令牌。
2. 备份可用配置。保留原订阅地址和本地修改，并单独记录覆写规则。不要只复制客户端程序目录，用户配置可能存放在其他位置。
3. 退出旧客户端。确保旧进程和后台服务不再占用代理端口。两个进程同时监听 127.0.0.1:7890 会产生冲突，错误可能表现为启动失败或代理不可用。
4. 先导入，再核对。在新客户端启用目标配置，查看日志是否存在未知字段、节点类型不支持或策略组引用不存在等错误。
5. 先测显式代理入口。暂不启用 TUN，按新客户端实际端口设置应用代理，分别检查网页连接、域名解析和规则命中情况。
6. 最后启用系统接管。按需要打开系统代理或 TUN，补齐权限，再测试本地网络、休眠恢复和应用分流。每次只改变一个变量。

日志中出现 address already in use，优先查端口占用；出现配置解析错误，优先查字段与缩进；只有特定应用失效，则检查该应用是否使用系统代理、独立 DNS 或自己的网络栈。不要看到连接失败就先换节点。

常见问题：内核更新、订阅识别与选择顺序

更新客户端，会自动更新 mihomo 吗？

不一定。客户端可能随安装包绑定内核，也可能支持单独下载内核。界面显示的软件版本不等于内核版本。更新后应重新查看内核运行信息，必要时检查启动日志；不能仅凭“检查更新”提示已是最新版，就断定内核已经更新。

订阅标注 Clash，可以直接给 mihomo 用吗？

多数常见 Clash YAML 配置具备迁移基础，但仍需检查协议、扩展字段和客户端覆写。订阅也可能根据请求的客户端标识返回不同内容。若原链接返回的是节点 URI 列表而不是完整 YAML，还要确认新客户端是否支持该导入方式，不能把所有“订阅链接”当作同一种文件。

同一个 mihomo 内核，为什么桌面能用、手机不能用？

先比较运行配置，而非只比较订阅地址。手机端还受 VPN 授权、分应用列表、后台限制和其他 VPN 占用影响；桌面端则可能受系统代理、防火墙和服务权限影响。协议支持相同，只排除了一类差异，没有排除整条网络路径的差异。

最后该先选内核，还是先选客户端？

先列出所需协议、系统平台和接管方式，再找支持这些条件的维护中客户端。需要图形操作就选择适合平台的界面；需要服务器部署或自动化管理，可直接研究 mihomo。接着核对实际内核版本，最后导入配置。完整操作流程见使用指南，故障定位可查完整文档。