Clash 开源生态关系梳理：mihomo 内核与 FlClash、Clash Verge Rev 等客户端的分工

先区分四层：内核、客户端、配置与服务

搜索 Clash 下载时，常会同时看到 mihomo、FlClash、Clash Verge Rev 和 Clash for Windows。这些名称并不处于同一层。选型前先确认需要的是运行代理的内核，还是带订阅管理和系统设置界面的客户端，能减少下载错误和迁移时的误判。

FlClash 安装成功，不代表已经具备可用的远端连接。客户端通常还需要导入有效配置，并选择策略组中的出站。反过来，订阅仍然有效，也不能保证一个长期未更新的旧内核可以识别其中的所有协议和字段。

原版 Clash、Clash Meta 与 mihomo 的关系

原版 Clash 是生态起点，不是所有客户端的统称

原版 Clash 是基于 Go 的规则代理项目，建立了广泛使用的 YAML 配置与规则表达方式。历史上还存在 Clash Premium，与开源版本的功能范围并不完全相同。旧教程中关于 TUN、规则集或脚本的描述，需要结合当时使用的内核判断，不能直接视为所有 Clash 项目的共同能力。

2023 年 11 月前后，原版 Clash 及部分相关客户端的公开项目发生停止维护、仓库移除等变化。现今仍能找到旧安装包和镜像，但“还能启动”与“持续适配新协议和新系统”是两件事。处理新配置时，应先确认具体项目及其维护状态。

Clash Meta 后续采用 mihomo 名称

Clash Meta 是沿 Clash 生态发展而来的分支，后来项目更名为 mihomo。旧文档、旧配置说明和部分界面仍可能使用 Meta 字样，因此看到“Meta 内核”时，通常需要进一步核对是否指向 mihomo 的相应版本。

mihomo 继续扩展协议支持、DNS、规则和 TUN 等能力，但它不是原版项目简单更换文件名后的同一份程序。某个字段是否支持，应以实际运行的 mihomo 版本及对应文档为准。也不能因为客户端支持 YAML，就推断它能识别全部 mihomo 扩展语法。

• 旧教程写 Clash：先分清是在泛指配置生态，还是特指原版内核。
• 订阅标注 Meta：重点检查配置实际使用的协议、规则和 DNS 字段。
• 安装包写 FlClash：这是图形客户端名称，内核版本需要另外查看。

FlClash 与 Clash Verge Rev：平台覆盖与使用差异

FlClash 和 Clash Verge Rev 都属于图形客户端，而不是订阅服务。选型时先按操作系统缩小范围，再比较配置管理与系统集成需求。下表描述项目的平台定位；具体可下载的架构和安装格式，以对应发行包为准。

Android 与 iOS 不能按名称互换

FlClash 提供 Android 端，但不能由此推断存在对应的 iOS 官方安装包。Clash Verge Rev 也不是 Android 客户端。iOS 用户需要选择适用于该系统的其他客户端，并核对订阅格式、规则语法和网络扩展能力，不能把 Android APK 或桌面安装包用于 iOS。

平台相同，也要核对处理器架构

macOS 的 Apple 芯片与 Intel 设备应分别核对 arm64、x64 安装包；Android 通常需要区分 arm64-v8a 与 armeabi-v7a。Linux 还需检查发行版适用的包格式。下载前可在系统的设备信息中确认架构，再到下载页选择对应客户端。

界面技术栈并不能直接推导出连接更快或更稳定。远端服务质量、网络路径、所选协议、DNS 和规则命中往往更直接地影响结果。比较客户端时，应该使用相同配置和同一网络条件，而不是拿不同订阅的表现作结论。

同为 mihomo 内核，为什么导入后的结果不同

订阅地址并不一定只返回代理列表。它可能返回完整 YAML，也可能返回需要客户端解析的节点内容，还可能根据请求参数返回不同格式。先区分“能下载订阅”“能解析配置”和“能建立连接”这三个阶段，再定位差异。

1. 内核版本不同：两个客户端各自捆绑的 mihomo 版本可能不同，新字段在旧内核中可能报错，或不能按预期工作。
2. 配置处理不同：客户端可能通过覆写、合并或订阅处理功能修改 DNS、端口、规则与策略组。原始订阅相同，不代表最终配置完全相同。
3. 策略组选择不同：规则指向同名策略组，但客户端保存的实际选择可能不同。需要展开策略组确认当前出口。
4. 运行环境不同：系统代理、TUN 权限、防火墙、已有 VPN 与 DNS 缓存都可能改变流量路径。

用最小规则片段理解配置依赖

下面只是规则片段，不是可独立运行的完整订阅。使用前必须已有名为 PROXY 的策略组，且该组已配置可用出站。规则按从上到下的顺序匹配，命中后不再继续寻找后面的规则。

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

这里的 example.org 仅用于展示域名后缀规则。no-resolve 表示不为这一条 IP 规则主动触发域名解析，不代表关闭整个客户端的 DNS。若导入后提示找不到 PROXY，应检查策略组定义，而不是反复重装客户端。

系统代理、混合端口与 TUN 分别由谁处理

客户端负责协调系统设置，内核负责实际处理进入的连接。以混合端口 7890 为例，mihomo 可以在同一端口接受 HTTP 与 SOCKS5 代理请求；客户端开启系统代理后，会把操作系统的代理设置指向相应入口。这里的端口仅为示例，实际值以当前配置为准。

mixed-port: 7890
allow-lan: false
mode: rule

在这段示例中，allow-lan: false 不允许其他局域网设备通过该入口访问代理。若只是本机使用，没有必要为了排查连通性直接打开局域网访问。系统代理也不等于全部应用接管：不读取系统代理设置的程序，可能仍然直接联网。

TUN 是网络接管方式，不是新的远端节点

TUN 通过虚拟网络接口把流量交给内核处理，适用于部分不遵循系统代理的程序。桌面端通常需要管理员权限、服务组件或相应系统授权；Android 端通常通过系统 VPN 接口接管流量。两者的权限路径与系统限制并不相同。

TUN 不会自动修复失效订阅，也不能替代正确的 DNS 和路由设置。同一设备上的其他 VPN、虚拟网卡或安全软件可能与其产生冲突。启用后若出现本地打印机、局域网服务或域名访问异常，应检查路由排除与 DNS 处理，而不是立即更换所有节点。

• 浏览器使用正常，某个应用失败：先确认该应用是否读取系统代理，再考虑 TUN。
• 两个客户端轮流测试：先退出前一个客户端，避免同时占用 7890 或反复改写系统代理。
• 开 TUN 后才出问题：对照关闭状态检查权限、路由和其他 VPN，不要同时改动订阅与规则。

从旧客户端迁移：按四步保留可验证结果

迁移的重点不是复制整个旧程序目录，而是分离可复用配置与客户端自身状态。旧客户端的数据库、缓存和设置文件不一定能被新客户端识别，直接覆盖可能带来额外问题。

1. 保存必要信息。备份订阅地址、自建配置和自定义规则，记录原来的端口、策略组选择与 DNS 设置。订阅地址可能含访问令牌，不要放入公开截图。
2. 先运行基础配置。退出旧客户端，在 FlClash 中导入订阅并选择当前配置。先检查解析错误，再用系统代理验证常用网站，不急于启用 TUN 或自定义覆写。
3. 逐项恢复调整。按规则、DNS、局域网访问、TUN 的顺序恢复需求，每次只改一项。若某一步失败，就回看这一项的设置和日志。
4. 记录运行信息。保留客户端版本、mihomo 版本、操作系统、报错文本和复现步骤。客户端版本与内核版本属于两套编号，不能互相替代。

如果原来使用完整 YAML，迁移时可以先保留其结构，再处理客户端覆盖项；如果原来只导入节点列表，则需要确认新客户端如何生成策略组和规则。不要假设换一个界面后，旧客户端的本地规则也会随订阅自动出现。

按需求选型，而不是按名称的新旧判断

• Windows 与 Android 都要使用：可先评估 FlClash，核对两端所需协议、配置处理方式和权限条件。
• 主要在桌面管理多份配置：可对比 FlClash 与 Clash Verge Rev 的配置切换、覆写和系统集成方式，选择更符合操作习惯的一项。
• 路由器、服务器或自动化环境：可评估直接运行 mihomo，但需要自行管理配置、进程、日志和访问权限，不一定需要图形客户端。
• 继续使用停止维护的旧客户端：应先确认新订阅能否解析，以及当前操作系统是否兼容，再制定迁移计划。

最实用的判断顺序是：操作系统支持、内核能力、订阅兼容、系统接管方式，最后才是界面偏好。需要并排比较平台支持时，可查看客户端对比；已经导入但无法联网时，按问题诊断区分配置错误、系统代理和 DNS 问题。这样能把“客户端选错了”与“当前配置有问题”分开处理。