先分清四层：内核、客户端、面板与配置
下载页面里的 Clash 有时指代理内核，有时指带界面的应用，也可能只是指兼容 Clash YAML 的配置格式。判断两个项目的关系，先看它负责哪一层，再看它实际装载的内核名称与版本；仅凭软件名称里有没有 Clash，无法确定协议支持、规则语法或 TUN 能力。
| 层级 | 实际职责 | 可核对的信息 |
|---|---|---|
| 代理内核 | 解析配置、解析 DNS、匹配规则、建立出站连接 | 内核名称、版本输出、启动日志 |
| 图形客户端 | 管理订阅、生成运行配置、控制进程与系统代理 | 应用版本、服务模式、内核选择设置 |
| 控制面板 | 通过控制接口查看连接、切换策略与读取日志 | 控制接口地址、认证设置、面板版本 |
| 订阅与配置 | 提供节点、策略组、规则及相关资源引用 | YAML 内容、生成目标、字段兼容性 |
例如，图形客户端能正常打开，只能说明界面进程运行成功；内核配置校验失败时，代理仍可能没有启动。反过来，关闭界面后若后台服务仍在运行，连接也可能继续经过代理。排障时应分别检查界面、内核进程和系统代理状态。
项目谱系：Clash、Premium、Meta 与 mihomo
原版 Clash：规则代理内核的起点
原版 Clash 通常指 Dreamacro/clash 项目，是用 Go 编写的规则代理内核。它建立了这一生态常见的配置组织方式，包括 proxies、proxy-groups、rules 和 dns。原版项目在 2023 年停止公开维护，旧二进制仍能运行，不代表它会继续获得协议适配或系统兼容更新。
Clash Premium 是历史上的另一条发行线，增加过 TUN、规则提供器、脚本等能力，不能把它当作原版开源内核任意版本都具备的功能集合。Premium 的增强部分并未完整开源，因此“Clash 生态包含开源项目”与“所有冠以 Clash 的发行物都公开全部源码”是两件事。
Clash.Meta：扩展协议与规则能力的分支
Clash.Meta 是从 Clash 发展而来的分支，扩展了协议支持、DNS、嗅探和 TUN 等能力。旧教程里的 Meta、Clash Meta 和文件名中的 clash-meta，通常是在描述这条分支。它不是原版内核上打开的一个开关，也不是只换了外观的客户端。
mihomo：Meta 项目的后续名称
MetaCubeX 维护的 Clash.Meta 后续更名为 mihomo，当前识别项目时应核对 MetaCubeX/mihomo 仓库、发布记录与二进制版本。旧配置、旧路径和客户端界面仍可能保留 Meta 字样；名称没有全部同步替换，并不自动表示它使用了另一套内核。
Dreamacro/clash
├─ 原版开源内核
├─ Clash Premium（历史增强发行线）
└─ Clash.Meta（分支）
└─ mihomo（Meta 项目后续名称）
图形客户端 → 启动、配置或嵌入内核
控制面板 → 连接内核的控制接口Verge Rev、ClashX 与 Nyanpasu 分别处在哪一层
这些名称主要指图形客户端。客户端负责系统托盘、订阅管理、权限申请等交互，协议与规则执行则主要由所带内核完成。应用更新与内核更新可以是两条独立的版本线，记录问题时应同时提供两者。
| 项目 | 平台与定位 | 内核关系与选型检查 |
|---|---|---|
| Clash Verge Rev | Windows、macOS、Linux 图形客户端 | 主要围绕 mihomo 构建；核对发行包内核版本、服务模式与配置合并结果。 |
| Clash Nyanpasu | 桌面图形客户端 | 提供内核管理能力；可用内核及渠道随版本变化，不能只按应用名判断当前运行的是哪一种。 |
| 原版 ClashX | macOS 菜单栏客户端 | 历史上围绕原版 Clash 构建；不要把它与 ClashX Pro 或 ClashX Meta 的能力合并理解。 |
| ClashX Pro | macOS 历史增强发行版本 | 与 Premium 内核相关；旧教程中的增强模式不能直接套到原版 ClashX。 |
| ClashX Meta | macOS 菜单栏客户端分支 | 面向 Meta／mihomo 内核路线；具体内核仍以该发行包的说明和运行日志为准。 |
| Clash for Windows | 历史桌面客户端 | 项目已停止维护，常见历史发行版使用 Premium；应用名称不能代表当前 Windows 客户端生态。 |
同名分支要核对维护者与发布记录
原版 Clash Verge 与 Clash Verge Rev 不是同一个持续发布的项目。Rev 是后续独立维护的分支，不能用原项目的停更状态推断 Rev 的状态，也不能把两边版本号串成一条更新序列。ClashX 的不同分支同样需要逐项确认，尤其要检查系统最低版本、处理器架构和内核来源。
查看 macOS 安装包时，应区分 Apple Silicon 的 arm64 与 Intel 的 x86_64。即使应用通过兼容层成功启动，后台辅助程序的架构、安装位置与权限仍需单独确认。iOS 则受系统网络扩展机制约束，桌面端安装辅助服务的步骤不能直接迁移到 iPhone。
“兼容 Clash 配置”不等于所有字段都能运行
Clash YAML 是一个共享基础，而不是对所有内核版本都一致的能力承诺。旧内核可能不支持较新的协议、嗅探选项或 DNS 字段；有些字段会导致启动失败，有些字段可能未按预期生效。客户端能够导入订阅，也不能证明每个节点都已经完成连接测试。
迁移前检查三类差异
- 节点协议：检查每个节点的
type及其参数。以 Hysteria2、TUIC 等节点为例，应核对目标 mihomo 版本的支持范围，不能按原版 Clash 的能力推断。 - 规则与资源：检查
rule-providers的格式、behavior与更新路径；出现RULE-SET时，要确认对应资源名称实际存在。 - 系统接管：检查
tun、DNS 劫持、路由与权限要求。配置语法被接受和系统路由成功安装是两个验收步骤。
同一份订阅，最终运行配置可能不同
客户端可以在下载订阅后追加规则、改写端口或合并 DNS 设置。因此，配置页里保存的原始 YAML 不一定是内核最终读取的文件。出现“同一订阅在另一客户端正常”的情况，应优先对比运行配置，而不是重复导入十几次。
# 7890 是本例设置，不是所有客户端的固定端口
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port: 7890 表示在同一端口接受 HTTP 与 SOCKS 代理连接。它不是控制接口端口，也不会自动开启 TUN。如果客户端启用了端口覆盖，系统代理应指向最终生效的端口；仅修改订阅里的数字可能不会改变运行结果。上例只是字段片段，不包含节点与完整分流规则。
如何确认正在运行的内核，而不是只看应用标题
不同客户端的菜单命名会随版本变化，核验应使用可交叉验证的信息：界面里的内核条目、日志中的启动记录，以及实际二进制的版本输出。客户端关于页的版本号只描述外壳，不能替代内核版本。
- 记录应用版本：打开客户端的“关于”或版本信息区域，记录完整应用名称、版本与操作系统架构，避免只写“最新版”。
- 定位内核信息：在设置中查找“内核”“Core”或内核管理入口，记录当前选中的名称与更新渠道；不要把下载列表里的其他内核当成正在运行的内核。
- 核对启动日志：重新加载配置后查看日志，确认内核启动成功、配置路径正确，并检查是否出现未知代理类型、资源加载失败或端口占用。
- 核对运行文件：需要进一步排障时，对客户端实际使用的二进制执行版本命令；另行下载的同名文件只能说明那个文件的版本。
# macOS / Linux：当前目录中已有 mihomo 和 config.yaml
./mihomo -v
./mihomo -t -f ./config.yaml
# Windows PowerShell：当前目录中已有 mihomo.exe 和 config.yaml
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml-v 用于查看版本，-t 用于测试配置，-f 指定配置文件。语法测试通过只说明配置通过该版本的检查，不表示远端节点可达，也不表示 TUN 权限已获批准。配置引用本地规则、证书或提供器文件时，还需保证路径和运行目录与实际环境一致。
按任务选客户端：先验证配置，再验证系统接管
需要较新协议或 mihomo 专用字段
选择明确说明采用 mihomo 的客户端，再核对内核版本与字段支持。不能因为客户端能显示节点名称，就认定协议已经兼容。最小验证路径是：配置测试通过、选择目标策略组、建立一次实际连接，再在连接页检查命中的规则与出站名称。
需要 TUN 接管不读取系统代理的应用
检查客户端是否提供对应平台的服务或辅助程序，以及系统是否批准所需权限。系统代理主要影响遵循代理设置的应用；TUN 则通过虚拟网络接口与路由处理流量，覆盖范围取决于路由、排除项及平台限制。TUN 不等于把所有流量强制送往代理，最终出站仍受规则、策略组和直连设置控制。
从旧客户端迁移到维护中的项目
- 备份订阅来源、手工规则、DNS 设置和策略组选择；不要仅保存界面截图。
- 在新客户端先导入一份配置，确认配置测试通过，再逐项恢复覆盖设置。
- 关闭旧客户端的系统代理与 TUN，确认旧后台服务不再接管流量，再启用新客户端。
- 核对代理端口，分别测试域名解析、规则命中和目标网站连接；遇到故障按这三个层次分别记录。
- 完成验证后再清理旧服务与开机启动项，避免两个程序争用同一监听端口。
选型时最有用的记录是“应用名称与版本、内核名称与版本、运行配置来源、系统接管方式”四项。应用外观决定操作路径，内核决定协议与规则能力，操作系统权限决定接管能否落地。将这三者分开核对，才能判断问题应该通过换客户端、更新内核，还是修正配置来解决。
需要横向核对平台支持，可查看客户端横向评测；需要理解策略组、规则与 DNS 的区别，可查阅概念速查。下载安装后，再按当前客户端提供的实际设置验证，不要混用其他分支的菜单截图。