Clash 开源生态项目关系图：内核分支、桌面客户端与移动端实现

搜索 Clash 时，常会同时看到 Clash、Clash Meta、mihomo、Clash Verge Rev、Clash Nyanpasu、FlClash、OpenClash 等名称。它们并不是同一个程序的不同安装包，也不都由同一团队维护。部分项目提供代理内核，部分项目只负责图形界面，还有一些项目面向路由器、Android 或特定桌面系统。

理解这些项目，关键不是先记住名称，而是先判断它位于哪一层：负责处理连接的内核、负责操作配置的客户端、负责系统接管的平台组件，还是负责下发节点与规则的订阅服务。只要层级分清，版本选择、配置兼容和故障定位都会直接许多。

先按四层拆开 Clash 生态

一套可以实际工作的 Clash 环境，通常由多个部分组合而成。名称里带有 Clash，不代表它一定包含原版 Clash 内核；名称里没有 Clash，也不代表它不能读取常见的 Clash 配置。项目之间更接近零件组合，而不是单一产品的版本序列。

订阅与本地配置
        ↓
图形客户端 / Web 控制面板
        ↓
Clash 系内核：Clash、Clash Meta、mihomo
        ↓
系统代理 / TUN / 路由器转发
        ↓
目标网络

第一层：订阅与配置

订阅地址一般返回 YAML 配置，内容可能包含代理节点、策略组、分流规则、DNS 设置和规则集引用。订阅服务不等于客户端，也不等于内核。客户端只是定时下载并管理这些配置，真正解析配置和处理连接的是内核。若订阅内容使用了某个分支专有字段，换到较旧内核时就可能出现解析错误。

第二层：客户端与控制面板

桌面客户端通常提供订阅更新、代理组切换、连接查看、日志展示、系统代理开关和 TUN 管理。它本身可能打包一个内核，也可能允许切换内核文件。Web 控制面板则通过外部控制接口连接内核，负责展示状态，不直接承担数据转发。

第三层：代理内核

内核负责监听端口、解析 DNS、匹配规则、选择策略组、建立代理连接并输出日志。相同的图形客户端，如果替换了不同内核，可用字段与运行行为也会变化。因此排查问题时，应同时记录客户端版本和内核版本，不能只写“Clash 最新版”。

第四层：系统接管

系统代理只影响遵循操作系统代理设置的应用。TUN 模式会创建虚拟网络接口，可覆盖更多不读取系统代理的程序。路由器部署则通过防火墙、策略路由和 DNS 转发接管局域网设备。三种入口最终都可以把连接交给内核，但权限要求、DNS 路径和排障方法不同。

原版 Clash、Clash Meta 与 mihomo 的分支关系

原版 Clash 是早期生态的核心基础。它确立了 YAML 配置、规则匹配、策略组、外部控制接口等常见结构。大量桌面客户端、路由插件和订阅模板都围绕这些接口建立。原版仓库停止持续维护后，生态没有整体停止，而是转向仍在维护的分支和兼容实现。

Clash Meta 最初以原版 Clash 的分支形式发展，扩展了代理协议、规则能力、DNS 行为、TUN 支持和配置字段。随后项目名称逐步转为 mihomo。现在看到“Meta 内核”和“mihomo 内核”时，通常是在描述同一条演进路线的不同阶段，而不是两个需要同时安装的独立内核。

mihomo 对常见 Clash 配置保持较高兼容度，但兼容并不表示所有字段可以无条件双向迁移。使用规则集提供者、特定 DNS 选项、新协议参数、流量嗅探或扩展规则类型时，应以目标内核当前文档为准。把 mihomo 配置直接交给旧版原始内核，最常见结果是未知字段、策略组引用失败或规则提供者加载失败。

桌面客户端是外壳，不是内核名称的同义词

Windows、macOS 和 Linux 用户通常先接触图形客户端。客户端把配置文件、内核进程、系统代理和托盘菜单组合到一个界面中，但它与内核仍是两个层次。客户端更新可能只修改界面和平台集成；内核更新则可能改变协议、DNS 或规则行为。发布说明中若分别列出应用版本与内核版本，就是这种分层的直接体现。

Clash Verge Rev

Clash Verge Rev 属于跨平台桌面客户端，常见于 Windows、macOS 和 Linux。它围绕 mihomo 提供订阅管理、策略切换、系统代理、TUN、连接记录和日志界面。名称中的 Rev 表示社区延续项目，不能与历史上名称相近但维护状态不同的项目混为一谈。

这类客户端适合需要可视化管理多个配置的桌面环境。安装时除了操作系统，还要核对处理器架构，例如 Windows 的 x64 与 ARM64、macOS 的 Intel 与 Apple 芯片。架构不匹配属于安装包选择问题，与订阅是否有效无关。

Clash Nyanpasu

Clash Nyanpasu 同样位于桌面图形层，提供配置管理、内核控制和系统集成。它与 Clash Verge Rev 可以使用相近的订阅内容，但界面实现、配置存储、升级流程和平台细节不同。两者通常是替代关系，不需要为了“补齐功能”同时运行。

ClashX 系名称

macOS 生态中长期存在 ClashX、ClashX Pro、ClashX Meta 等相近名称。它们的维护来源、内核组合和授权方式并不完全相同。看到名称时应继续检查仓库来源、最后发布版本、内核类型和支持的 macOS 架构。仅凭“X”或“Meta”字样无法判断项目是否仍适合当前系统。

桌面客户端之间迁移时，不建议直接复制整个应用数据目录。目录里除了 YAML，还可能包含数据库、窗口状态、服务权限信息、系统代理备份和旧内核文件。更稳定的方式是保留订阅地址与经过确认的本地覆写规则，在新客户端中重新导入，再逐项恢复 TUN、DNS 和开机启动设置。

移动端、路由器与 Web 面板的实现差异

移动端项目不仅要封装内核，还必须遵守系统提供的 VPN 接口和后台运行限制。Android 客户端一般通过本地 VPN 服务把应用流量送入内核，因此状态栏会显示 VPN 连接。此处的 VPN 是系统流量入口，不表示订阅节点一定采用传统 VPN 协议。

Android 客户端

Clash Meta for Android 曾是常见的 Meta 系 Android 实现，很多旧教程仍使用它的界面截图。判断是否继续使用时，应查看项目维护状态与内核更新时间。FlClash 等跨平台项目也可在 Android 上运行，并采用现代 Clash 系内核处理配置。不同应用的数据目录和本地备份格式通常不通用，但标准订阅地址可以重新导入。

Android 上若只有浏览器可用而部分应用无法连接，应检查应用分流、绕过列表、VPN 权限、省电限制和 IPv6 路径。若所有域名都失败，则优先查看 DNS 日志与配置解析结果。移动端故障不应只通过频繁更换节点处理，因为系统限制和内核配置属于不同层面。

iOS 与 iPadOS

iOS 平台需要通过 Network Extension 等系统机制实现网络接管，应用分发和后台资源也受到平台规则约束。市场上存在能够读取部分 Clash 风格配置或订阅的网络工具，但名称、内核和配置兼容范围各不相同，不能仅因为支持策略组就认定它属于原版 Clash 项目。

导入前应确认应用支持的是完整 Clash YAML、订阅转换后的节点列表，还是它自己的配置格式。若订阅中使用 mihomo 专有规则和 DNS 字段，移动端应用可能忽略、转换或拒绝这些内容。此时应为目标应用准备对应格式，而不是反复导入同一份桌面配置。

OpenClash 与路由器部署

OpenClash 是面向 OpenWrt 环境的管理与集成项目。它负责下载和启动内核、生成运行配置、接入防火墙、处理 DNS 转发并提供管理页面。实际流量仍由所选内核处理。OpenClash、mihomo 与 OpenWrt 分别对应管理插件、代理内核和路由操作系统，三者不能互相替代。

路由器部署比桌面客户端多出局域网转发、策略路由、透明代理和 DNS 劫持等环节。客户端显示节点可用，不代表路由器路径一定正确。出现局域网设备无法访问、国内域名解析异常或部分设备循环重连时，应依次检查内核日志、DNS 上游、IPv4 与 IPv6 规则、防火墙链和旁路由网关设置。

Web 控制面板

Yacd、MetaCubeXD 一类 Web 面板通过控制接口读取代理组、连接和日志。它们是操作界面，不是代理内核。关闭浏览器页面通常不会停止代理服务；反过来，面板可以打开也不代表内核已经正确接管流量。面板连接失败时应检查控制地址、监听范围、认证密钥和防火墙，而不是修改节点协议。

同一份订阅为什么在不同项目中表现不同

订阅能否导入，只说明客户端取得了一段内容；真正能否运行，还要经过配置解析、资源下载、DNS 初始化、监听端口建立和系统接管。不同项目在这些阶段采用的默认值并不相同，所以同一订阅在两台设备上可能得到不同结果。

1. 内核版本不同：较新的规则类型、协议参数或 DNS 字段可能不被旧内核识别。
2. 客户端覆写不同：客户端可能自动修改端口、控制接口、TUN、DNS 或配置目录。
3. 规则资源不同：远程规则集下载失败后，策略可能缺少关键匹配项，日志中通常会出现 provider 错误。
4. 系统入口不同：桌面端使用系统代理，移动端使用本地 VPN，路由器使用透明代理，接管范围自然不同。
5. DNS 路径不同：系统 DNS、内核 DNS、浏览器安全 DNS和路由器转发可能同时存在，最终查询不一定进入同一个解析器。
6. 策略选择没有同步：配置中的策略组默认项可能与旧设备保存的选择不同，导入后应重新核对当前策略。

排查时可以先使用最小路径：确认配置能够解析，选择一个已知可连接的节点，暂时关闭额外覆写，只保留必要 DNS 与规则，然后测试内核监听端口。内核直连测试通过后，再开启系统代理或 TUN。这样能区分是配置层、内核层还是系统接管层的问题。

检查顺序：
1. 订阅是否成功返回 YAML
2. 内核是否完成配置解析
3. 代理与规则资源是否加载
4. 本地监听端口是否建立
5. 系统代理或 TUN 是否接管
6. DNS 查询是否进入预期路径
7. 规则是否命中预期策略组

日志级别可先设为 info，观察配置加载、DNS、规则集和连接错误。只有在需要追踪具体请求时再临时提高日志详细度，避免大量重复记录掩盖关键错误。调整规则、DNS 与 TUN 时每次只改一个变量，并保留可恢复的原配置。

按维护状态、平台和配置需求选择项目

选择 Clash 系项目时，首先确认维护状态，其次确认平台与架构，最后确认所需功能是否由对应内核提供。项目名称接近、搜索结果靠前或旧教程数量多，都不能代替这些检查。

如果目标只是桌面浏览器和常规应用代理，维护活跃的桌面客户端通常更省操作步骤。如果需要接管游戏、命令行程序或不遵循系统代理的软件，再评估 TUN。若希望整个局域网统一分流，应考虑路由器方案，但要预留防火墙和 DNS 排障能力。服务器环境通常不需要桌面外壳，直接运行 mihomo 并交给 systemd 管理更清晰。

配置迁移应围绕标准 YAML、订阅地址和自建规则进行，而不是依赖某个客户端的内部数据库。内核专有字段要单独记录，确保下一项目确实支持。遇到旧教程时，先核对教程中的项目名称、发布时间和内核阶段，再决定哪些步骤仍然适用。

关系图的最终判断方法

看到一个新项目名称时，可以用四个问题定位：它是否包含代理内核；包含的是原版 Clash、旧称 Meta 还是 mihomo；它通过系统代理、TUN、本地 VPN 还是路由器防火墙接管流量；它的配置是标准 Clash YAML、扩展字段还是独立格式。四项答案明确后，项目在生态中的位置基本就确定了。

Clash 生态的延续依赖多个独立项目协作。mihomo 负责现代内核能力，桌面和移动客户端负责平台交互，OpenClash 负责路由器集成，Web 面板负责远程控制，订阅与规则项目负责配置数据。它们可以组合，但发布节奏、维护团队和兼容边界各自独立。选择时按层级核对，排障时按数据路径逐段检查，比把所有程序统称为“Clash 客户端”更准确。