Clash 开源生态全景:mihomo、Clash Verge、ClashX 与各分支项目的关系

先区分内核、客户端与配置

Clash 生态最容易混淆的地方，是多个项目名称都带有 Clash，但它们不处在同一层。原始 Clash、Clash.Meta 与 mihomo 主要属于代理内核；Clash Verge Rev、Clash Nyanpasu、ClashX 等属于图形客户端；订阅链接、YAML 文件、规则集则是交给内核读取的数据。判断一个项目的用途时，先确认它属于哪一层，比比较界面截图更有效。

内核负责实际网络处理

内核监听本地代理端口，建立到代理服务器的连接，并按照规则决定流量走向。常见工作包括解析 YAML 配置、维护代理组、匹配域名与 IP 规则、执行 DNS 策略、暴露 REST API，以及在支持的平台上接管 TUN 流量。下面是一段典型的内核基础配置：

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

这里的 7890 是 HTTP 与 SOCKS5 共用的混合端口，9090 是控制接口端口，1053 是示例 DNS 监听端口。图形客户端通常通过控制接口读取节点列表、切换代理组和查看连接记录。界面上的“选择节点”最终会转换为对内核 API 的调用。

图形客户端负责生命周期与系统集成

下载、更新和切换订阅配置。
启动、停止并监控内核进程。
设置系统代理，或创建 TUN 虚拟网卡。
提供代理组、规则、连接、日志和流量统计界面。
保存客户端自身设置，例如开机启动、托盘行为和内核路径。

因此，同一份订阅在两个客户端中表现不同，并不一定是订阅内容发生变化。差异可能来自内核版本、DNS 默认值、TUN 实现、客户端写入的覆写字段，或者客户端只展示了部分配置项。

原始 Clash、Clash.Meta 与 mihomo 的继承关系

原始 Clash 奠定配置与 API 结构

Dreamacro 维护的原始 Clash 使用 Go 编写，形成了这套生态最重要的兼容基础：YAML 配置、代理组、按顺序匹配的规则系统、HTTP 与 SOCKS 监听端口，以及外部控制 API。大量客户端最初都围绕这些接口开发。原始仓库在 2023 年停止维护并进入归档状态，此后继续依赖原始内核意味着不会再获得上游协议适配、平台兼容和网络栈修正。

历史上的 Clash Premium 是带有额外功能的独立发行线，曾提供规则集、脚本和更完整的 TUN 能力。它不是今天选择新客户端时应继续追踪的活跃开源主线。旧教程中出现的 rule-providers、tun 或 script 字段，需要结合实际内核判断，不能仅凭“Clash 配置”四个字推断兼容性。

Clash.Meta 扩展原有能力

Clash.Meta 由 MetaCubeX 社区维护，起点是兼容 Clash 配置与控制接口，同时扩展协议、DNS、规则、监听器与 TUN 功能。很多配置提供方过去把对应订阅标记为“Clash Meta”。这类订阅可能包含原始 Clash 不认识的代理类型或字段，因此把它直接导入旧版 ClashX、旧版 Clash for Windows 或原始 Clash 内核，可能出现解析失败，也可能静默忽略部分选项。

mihomo 是 Clash.Meta 的后续名称

Clash.Meta 后来更名为 mihomo。名称变化不代表配置体系被整体推翻：常见的 proxies、proxy-groups、rules、proxy-providers 和 rule-providers 结构仍沿用。实际迁移重点是客户端是否使用活跃的 mihomo 内核、内核版本是否满足配置要求，以及客户端有没有在启动前修改配置。

mihomo 的版本通常采用 v1.x.x 形式发布。排查问题时应记录完整版本号，而不是只写“Meta 内核”。客户端的「设置」→「内核」或「设置」→「版本」页面一般能查看该信息；不同项目的菜单名称略有差异。日志开头通常也会打印版本、Go 运行时与目标架构，例如 linux-amd64、windows-amd64 或 darwin-arm64。

桌面客户端分支分别解决什么问题

Clash Verge 与 Clash Verge Rev

Clash Verge 是使用 Tauri 构建的跨平台桌面客户端，界面层与代理内核分离。原项目停止维护后，Clash Verge Rev 作为社区延续分支持续适配 mihomo。两者名称接近，但维护状态和内核更新来源不同。新安装时应确认项目名称中是否明确为 Rev，并在「设置」→「内核设置」查看实际加载的 mihomo 版本。

Clash Verge Rev 适合需要 Windows、macOS 与 Linux 接近一致操作方式的用户。常用流程是「订阅」→「新建」添加订阅地址，更新后在「代理」页面选择策略组，再到「设置」开启系统代理或 TUN 模式。系统代理主要接管遵循操作系统代理设置的程序；TUN 模式则通过虚拟网卡处理更多类型的流量，通常还需要管理员权限和正确的路由、DNS 设置。

Clash Nyanpasu

Clash Nyanpasu 同样属于跨平台图形客户端，项目重点放在配置管理、内核管理和桌面交互。它不是 mihomo 的替代品，而是负责下载或调用内核、生成运行配置并展示内核状态。使用时应分别确认“客户端版本”和“内核版本”，因为只更新界面程序不等于代理内核已经更新。

Nyanpasu 适合需要管理多份配置、覆写和代理组的用户。遇到订阅更新后行为变化时，应依次检查「配置」中的当前启用项、覆写内容、内核选择和运行日志。若一份配置在命令行 mihomo 中可以启动，在 Nyanpasu 中失败，重点检查客户端合并后的最终配置，而不是只检查原始订阅文件。

ClashX、ClashX Pro 与 ClashX.Meta

ClashX 是较早出现的 macOS 菜单栏客户端，操作入口集中在状态栏图标中。其经典版本围绕原始 Clash 内核设计，适合解释许多旧版 macOS 教程中的菜单结构，例如“设置为系统代理”“出站模式”和代理组选择。由于原始内核已经归档，经典 ClashX 不适合依赖新协议、新规则集能力或新版本 macOS 网络变化的配置。

ClashX Pro 属于历史上的增强发行线，不能仅根据名称中的 Pro 推断它使用 mihomo。ClashX.Meta 则是面向 Meta 内核兼容需求出现的分支。三者图标和菜单可能相似，但内核来源并不相同。导入配置前，应打开「帮助」→「关于」或查看启动日志，确认内核名称与版本。只比较应用文件名，无法判断是否支持某个代理类型。

Clash for Windows

Clash for Windows 曾是使用范围较广的桌面客户端，但它不是开源项目，并已于 2023 年停止维护。大量旧教程仍使用其「Profiles」「Proxies」「General」和「Connections」页面作为示例。阅读这些教程时，可以理解其配置概念，但不应把页面路径直接套用到 Verge Rev 或 Nyanpasu。

从 Clash for Windows 迁移时，优先迁移订阅地址或原始 YAML，不要复制整个程序目录。旧目录中还可能包含客户端生成的合并配置、缓存规则集和本地覆写。新客户端重新导入订阅后，再逐项重建端口、局域网访问、TUN 与 DNS 设置，更容易定位差异。

移动端、路由器与网页面板的位置

移动端客户端是独立实现

Android 和 iOS 上的应用即使支持 Clash 格式，也不一定直接运行桌面端相同的内核二进制。移动系统对后台进程、VPN 接口、DNS 和电量管理有单独限制。Android 客户端一般通过系统 VPN API 建立 TUN；iOS 客户端则依赖 Network Extension。桌面端的“系统代理”开关在手机上没有完全对应的工作方式。

Clash Meta for Android 属于曾经常见的 Meta 系移动客户端，但判断是否继续使用时应查看仓库归档状态和最近发布记录。FlClash 等项目也可以使用 mihomo 能力，但其界面设置、配置存储和系统集成是客户端自己的实现。跨端复用配置时，建议共享订阅主体，把平台相关的 TUN、DNS 监听地址与局域网参数留在各设备本地。

OpenClash 是 OpenWrt 插件层

OpenClash 运行在 OpenWrt 环境中，负责内核部署、配置转换、规则更新、防火墙与 DNS 集成。它不是桌面客户端，也不是单独的代理协议。路由器上的流量接管涉及 nftables 或 iptables、策略路由、DNS 劫持和局域网地址段，复杂度高于桌面的系统代理开关。

例如桌面端常见的 mixed-port: 7890 只为本机应用提供代理入口；路由器透明接管则还要处理来自 LAN 设备的转发流量。把 allow-lan: true 打开，只表示允许其他设备连接代理监听端口，并不会自动完成网关转发、DNS 接管或防火墙放行。

Yacd、MetaCubeXD 属于 Dashboard

Yacd、MetaCubeXD 等项目是外部控制面板。它们连接内核的 REST API 与 WebSocket，显示代理组、活动连接、规则命中和流量数据。面板本身不处理代理流量，也不会替代 mihomo。若内核控制地址为 127.0.0.1:9090，只有本机能够直接访问；需要从局域网管理时，应谨慎调整监听地址，并设置强度足够的 secret 与防火墙规则。

订阅、配置与规则集如何在项目间流动

订阅链接返回的内容通常是一份 YAML 配置，也可能是经过编码的节点列表。客户端负责下载内容，必要时执行转换或覆写，然后把最终配置交给内核。所谓“支持 Clash 订阅”，至少包含三个层面：能识别文件格式、能识别其中的代理协议、能正确执行其中的 DNS 和规则字段。

完整配置与 Provider 配置

完整配置把节点、代理组和规则写在一个文件中；Provider 方案则把节点或规则拆成远程资源，由内核定期更新。下面的结构会每隔 3600 秒刷新一次节点提供器，并通过健康检查访问指定 URL：

proxy-providers:
  airport:
    type: http
    url: "https://example.invalid/subscription.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 3600 控制订阅刷新周期，health-check.interval: 600 控制健康检查周期，两者不是同一设置。测试 URL 返回速度只反映到该目标的请求耗时，不等同于下载带宽。规则按顺序匹配，MATCH 应放在末尾作为兜底。

客户端覆写会改变最终结果

端口覆写：客户端可能把订阅中的 mixed-port 改为本地指定端口。
DNS 覆写：启用 TUN 时，客户端可能插入 dns-hijack、Fake IP 或 nameserver 配置。
规则覆写：脚本或合并配置可能在原有规则前增加直连、拦截或进程规则。
代理组覆写：客户端可能保留本地选择，订阅更新后仍指向原来的节点名称。

排查兼容问题时，最有价值的是客户端实际传给内核的最终 YAML。若客户端提供「配置」→「查看运行配置」或「设置」→「打开配置目录」，应导出该文件并与订阅原文比较。日志中记录的配置路径也能帮助定位生成文件。

TUN、系统代理与内核差异

系统代理只覆盖主动读取代理设置的程序

开启系统代理后，客户端通常把操作系统的 HTTP 和 HTTPS 代理指向 127.0.0.1:7890。浏览器和多数桌面应用会读取该设置，但游戏、部分命令行程序、虚拟机和自行实现网络栈的软件可能绕过它。此时内核正常运行、浏览器可以访问，并不能证明所有进程都已进入代理。

TUN 通过虚拟网卡接管 IP 流量

mihomo 的 TUN 模式会创建虚拟网络接口，并配合路由与 DNS 设置接收流量。示例配置常见结构如下：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed 表示使用内核支持的混合网络栈策略，auto-route 请求自动写入路由，auto-detect-interface 用于识别默认出口。不同操作系统对管理员权限、网卡驱动和防火墙的要求不同。Windows 上切换 TUN 后完全断网，先检查客户端是否以所需权限运行，再检查其他 VPN、Hyper-V、WSL 或安全软件创建的路由。

客户端之间的 TUN 体验差异，往往来自启动顺序、路由清理、DNS 注入和休眠恢复处理，而不只是 mihomo 本身。比较两个客户端时，应使用同一份配置、相同内核版本和相同网络环境。一次测试可记录启动耗时、首个 DNS 响应、默认路由变化和休眠恢复后的连接状态，而不是只比较界面显示的内存数字。

维护状态应该怎样判断

项目名称延续不代表维护活动延续。选择客户端时，应同时检查代码仓库、发布页和依赖内核，而不是只看下载页面上的版本字符串。原始 Clash、Clash for Windows、经典 ClashX 与各类社区分支的状态并不相同。

四项可验证信号

最近发布：查看正式版本发布时间、变更记录和各平台安装包是否同时生成。
内核来源：确认使用原始 Clash、mihomo，还是客户端自带的其他兼容内核。
问题处理：检查与当前 Windows、macOS、Linux 版本相关的问题是否有人分类和修复。
升级路径：确认客户端升级是否覆盖内核升级，以及失败后能否手动回退。

版本号不能跨项目直接比较。Clash Verge Rev 2.x、Nyanpasu 2.x 与 mihomo v1.x.x 分别属于不同软件，数字大小没有继承关系。报告故障时，应同时写明客户端完整版本、mihomo 完整版本、操作系统版本、CPU 架构、当前模式和关键日志。例如“Windows 11 24H2、x64、客户端 2.x、mihomo v1.x.x、TUN mixed 栈”比“最新版不能用”更容易定位。

不要依赖应用名称推断架构

macOS 安装包可能同时提供 x64 与 arm64，Apple 芯片设备应优先选择 arm64 构建。Windows 设备常见 x64，部分新设备使用 arm64。Linux 还需要区分 AppImage、deb、rpm 以及系统库要求。架构不匹配时，即使应用可以通过转译启动，TUN 辅助程序或内核二进制仍可能失败。

按使用场景选择项目

Windows、macOS、Linux 统一操作

需要三类桌面系统保持接近的配置管理方式，可优先考察 Clash Verge Rev 或 Clash Nyanpasu。选择时重点比较当前系统上的 TUN 支持、配置覆写能力、内核更新机制和日志入口。只使用浏览器代理的场景，系统代理稳定性比复杂的 TUN 选项更重要。

macOS 菜单栏轻量操作

偏好菜单栏交互时，可以考察仍在维护并明确使用 mihomo 的 macOS 客户端。若继续使用经典 ClashX，应明确它的内核能力边界，并避免导入包含 mihomo 专属字段的配置。升级 macOS 大版本前，先确认客户端对新系统网络权限和后台启动机制的适配情况。

路由器统一接管家庭设备

电视、游戏机和物联网设备无法单独安装客户端时，OpenWrt 配合 OpenClash 属于常见方案。部署前应确认路由器 CPU 架构、可用内存、闪存空间和防火墙体系。规则集较大、连接数较高或启用复杂 DNS 时，资源需求会明显高于简单的本地端口代理。

只需要内核与远程面板

服务器或精简 Linux 环境可以直接运行 mihomo，通过 systemd 管理进程，再用 MetaCubeXD 等 Dashboard 连接控制端口。此方案需要自行处理配置目录、文件权限、日志轮转和升级。控制接口不应直接暴露到不受信任的网络，远程访问可通过防火墙、反向代理认证或安全隧道限制。

迁移旧客户端的操作顺序

记录当前参数：保存订阅地址、当前代理组选择、本地覆写、监听端口和局域网设置。
导出原始配置：优先保存订阅 YAML，不把缓存、日志和客户端数据库当作可移植配置。
安装新客户端：确认系统架构，再在「设置」→「内核」检查 mihomo 版本。
先测试系统代理：使用默认 7890 或客户端显示的实际端口，确认基本规则与 DNS 正常。
再启用 TUN：记录启用前后的路由和 DNS 变化，出现断网时可以快速回退。
重建覆写：逐项加入规则、DNS 和局域网配置，每次修改后重新载入并查看日志。

如果旧配置包含脚本模式、Premium 专属字段或过时的代理类型，应先查明对应功能在 mihomo 中的替代写法。不要一次性复制旧客户端的全部合并配置，因为其中可能包含绝对路径、旧端口、旧网卡名称和平台专属字段。

迁移完成后，可进行三组检查：浏览器通过系统代理访问、命令行显式指定 http://127.0.0.1:7890 访问、启用 TUN 后测试不读取系统代理的程序。三组结果能区分订阅问题、系统代理问题和 TUN 路由问题。