先区分三层：内核、图形客户端与订阅

搜索“Clash 下载”时，结果可能同时包含命令行程序、桌面安装包和手机应用。它们不在同一层：内核负责执行代理与分流，图形客户端负责管理和启动内核，订阅负责提供节点或配置数据。把这三层分开，才能判断“换客户端能不能解决问题”。

  • 内核：监听代理端口、建立出站连接、匹配规则、处理 DNS；mihomo 就属于这一层，可以脱离图形界面独立运行。
  • 图形客户端：管理订阅、选择策略组、切换系统代理、安装后台服务，并展示内核日志与连接记录。
  • 订阅：可能只提供节点列表，也可能提供含 DNS、规则和策略组的完整 YAML；订阅服务不是内核项目本身。

例如，客户端窗口显示“运行中”，只说明某些进程或服务已经启动，不代表订阅中的节点能连通。反过来，浏览器能通过 127.0.0.1:7890 上网，也不能证明 TUN 已接管整台设备。先找到问题所在的层，再决定升级什么，通常比反复重装省时间。

原版 Clash、Premium、Meta 与 mihomo 的演进

原版 Clash：配置模型与规则体系的起点

Dreamacro/clash 是这一生态的重要起点，使用 Go 编写，原版开源内核采用 GPL-3.0 许可。很多仍在使用的配置概念由此延续下来，例如 proxies、proxy-groups、rules，以及规则从上到下匹配的工作方式。2023 年 11 月前后，原项目停止公开维护，历史客户端与教程并没有因此从互联网上消失。

这也是旧教程容易造成误会的原因：它们讲解的 HTTP 代理和规则顺序可能仍然适用，但安装包、内核能力与系统权限设置已经不是同一个环境。看到“Clash 支持某字段”，还需要追问一句：指的是哪一个内核、哪个构建？

Clash Premium：不是 mihomo 的“付费高级版”

Clash Premium 是原生态中单独分发的闭源内核分支，曾提供 TUN、脚本等扩展能力。这里的 Premium 是分支名称，不能直接理解为某个图形客户端的付费套餐。由于其完整实现并未开源，不能把后来的 mihomo 画成“公开 Premium 源码继续更新”的简单直线。

原版开源 Clash、Premium 与 Meta 的功能存在交集，但配置并非逐项等价。尤其是旧 Premium 脚本规则，不能仅把可执行文件换成 mihomo 就假定继续生效；迁移时应改写为目标内核支持的规则和策略组。

Clash.Meta → mihomo：名称变化与功能扩展

Clash.Meta 是基于 Clash 开源代码发展出来的社区分支，后改名为 mihomo，仓库标识为 MetaCubeX/mihomo。因此，旧文档里的“Meta 内核”、订阅平台里的“Clash Meta 格式”，经常对应现在讨论的 mihomo 生态，而不是另一个必须同时安装的程序。

mihomo 延续了 Clash 风格的 YAML 配置与控制接口，并持续扩展协议、规则与 DNS 能力。它采用 GPL-3.0 许可，但使用 mihomo 的图形客户端可能采用不同许可证；分析软件许可时，要分别查看前端和内核的 LICENSE，而不是只读安装包名称。

关系示意：箭头含义分别标注
原版 Clash 开源代码
  └─ 社区分支发展 → Clash.Meta
                       └─ 项目更名 → mihomo

Clash Premium
  └─ 原生态的闭源内核分支；不是 mihomo 的公开源码上游

Clash Verge Rev / FlClash 等图形客户端
  └─ 打包、启动并通过控制接口管理 → mihomo

Verge、FlClash、Nyanpasu 分别处在哪一层

这些名称主要指图形客户端，不是三套完全不同的代理协议。它们可能调用同一类内核，却在订阅合并、后台服务、系统代理设置和更新策略上表现不同。下面按项目关系区分，不把界面相似当作代码继承证据。

项目名称所处层级选型时重点核对
mihomo代理内核内核版本、配置字段、目标架构；不自带完整桌面管理界面
Clash Verge历史桌面客户端原项目已归档，不能与 Rev 的发布记录混用
Clash Verge Rev延续 Verge 路线的桌面客户端Windows、macOS、Linux 安装包及其随包 mihomo 版本
FlClash基于 Flutter 的图形客户端桌面端、Android 端的功能差异，以及实际打包的内核
Clash Nyanpasu源于 Verge 路线的桌面客户端当前发行版可用的内核选项、配置增强方式与服务模式
Clash for Windows历史桌面客户端已停止维护；名称中的 Windows 不等于只曾支持 Windows
Clash for Android历史 Android 客户端已停止维护；不要仅凭能够安装就判断支持新配置

Clash Verge 与 Clash Verge Rev 要分开识别

“Verge”常被当作简称，但原版 Clash Verge 与后续 Clash Verge Rev 不是同一个发布入口。Rev 延续了原项目路线，使用 mihomo 内核。搜索到旧版安装说明时，应先核对项目全名与发布仓库，再看操作截图；同名菜单可以保留，后台服务实现却可能已经调整。

FlClash 与 FlClashs 不应直接视作同一发行版

FlClash 使用 Flutter 构建界面，覆盖桌面与 Android 等平台。若下载列表中还出现 FlClashs，应将其作为另一个分发名称单独核对维护者、仓库、包名及说明，不能因只多一个字母就默认更新记录通用。站点展示名、安装后的应用名和上游项目名，有时并不完全一致。

Nyanpasu 的内核选择以实际发行版为准

Clash Nyanpasu 同样属于图形管理层。其不同阶段的发行版可能提供不同的内核选项，因此不能把某张旧截图中的切换菜单当作永久功能清单。排障时记录“客户端版本 + 当前选中内核 + 内核版本”三项；只报“使用 Nyanpasu”不足以判断某条配置能否解析。

为什么同一份订阅，在两个客户端表现不同

订阅兼容性不是一个开关。相同 URL 导入后，客户端可能发送不同的请求头，服务端据此返回不同内容；即便返回内容一致，客户端还可能添加本地覆写，最后交给不同版本的内核执行。比较时应检查实际生效配置，而不只是订阅编辑框里的原文。

  1. 检查返回格式：完整 Clash YAML 通常包含 proxies 或 proxy-providers 等字段；仅有节点链接列表的内容，未必能当作完整配置直接加载。
  2. 检查内核支持：旧内核不保证支持新协议或新字段。日志出现 unsupported proxy type 一类错误时，先确认内核，而不是反复更新同一订阅。
  3. 检查本地覆写：客户端可能覆盖 mixed-port、dns、tun 和 external-controller。原配置写了 7890，最终监听端口不一定仍是 7890。
  4. 检查规则引用：规则里的策略组名称必须与实际名称一致。MATCH,PROXY 中的 PROXY 是引用名称，不是任何配置都自动拥有的保留组。

用命令确认：正在运行的到底是哪一个内核

不要靠安装包文件名猜测。先在客户端的“关于”或内核信息页面记录版本；入口名称因发行版而异。若要检查独立内核文件，可在其目录执行下面的命令。这里的文件名采用 mihomo 常见命名，实际文件名不同则按本地文件调整。

Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\config.yaml
macOS / Linux
./mihomo -v
./mihomo -t -d . -f ./config.yaml

-v 输出内核版本；-t 检查配置；-d . 将当前目录设为工作目录，便于定位本地数据文件。含远程规则集或其他资源的配置，检查过程也可能受网络和文件路径影响。配置测试通过只代表通过相关检查，不代表所有节点都已建立连接。

若客户端已启用本地控制接口，也可以读取版本。下面仅适用于控制地址为 127.0.0.1:9090、且未配置控制密钥的本机环境；有密钥时需要按配置添加 Bearer 认证，不要为了执行示例而删除密钥。

读取运行中内核的版本信息
curl http://127.0.0.1:9090/version

从旧客户端迁移：按配置、权限、流量三步验收

第一步：备份输入，不整目录覆盖

保留订阅地址、本地规则、策略组选择记录和覆写脚本。先在新客户端重新导入订阅，再逐项迁移本地修改；不要把旧应用的数据目录整体覆盖到新应用目录。两者的数据库结构、路径约定和脚本接口可能不同，YAML 相似不代表内部存储也兼容。

第二步：先测显式代理，再开启 TUN

在新客户端确认实际 mixed-port。假设是 7890，可以先用以下命令检查显式 HTTP 代理链路。示例域名用于测试命令形式，返回状态取决于当前网络与规则，不预设某个“实测延迟”。

通过本地代理发送 HTTPS 请求
curl -I --proxy http://127.0.0.1:7890 https://example.com

显式代理能够工作后，再测试系统代理和 TUN。系统代理主要影响遵循系统设置的应用；TUN 通过虚拟网络接口接管流量，通常还需要后台服务、管理员权限或平台 VPN 授权。Android 上相关客户端一般通过系统 VPN 接口工作，与桌面端的服务安装流程不同。

第三步：检查 DNS、UDP 与休眠恢复

  • DNS：对比普通网页访问与应用内访问，确认系统解析请求是否按预期接管；启用 TUN 不自动等于所有加密 DNS 都已受控。
  • UDP：语音、游戏和 QUIC 还依赖节点与协议支持；网页能打开不能替代 UDP 验收。
  • 休眠恢复：设备休眠后重新联网，检查后台内核是否仍在运行、系统代理端口是否仍有监听。
  • 关闭回退：退出客户端后确认系统代理恢复；若系统仍指向已关闭的 7890 端口，表现会像“整个网络断了”。

选型结论：核对维护链，而不是只认名字

桌面用户可以先比较 Clash Verge Rev、FlClash 与 Clash Nyanpasu 的配置管理方式、服务权限和内核更新入口；Android 用户重点检查系统 VPN 授权、后台运行限制及当前发行包支持的平台架构。iOS 用户则应单独确认具体应用的配置兼容范围，不能把桌面 mihomo 的全部能力直接平移过去。

最终需要记录的是一条可追溯的链：安装包来源 → 客户端发行版 → 实际内核版本 → 最终生效配置。只更换界面，不一定能修复协议兼容问题；只升级内核，也不一定能修复系统代理残留。把层级写清楚，再看日志，项目族谱就从名字接龙变成了排障工具。

需要核对安装步骤时可查看全平台指南；不熟悉 TUN、策略组等术语时可先读名词解释。下载时选择对应系统和处理器架构，并留意客户端的维护状态。