Clash 开源项目关系图:原版内核、Meta 与 mihomo 及各图形客户端如何分工

内核、客户端与配置的分工

选择 Clash 桌面客户端，先分清三个对象：负责处理连接的内核、提供设置界面的图形客户端，以及描述节点和规则的配置文件。名称里都有 Clash，不代表使用同一套内核，也不代表能读取完全相同的配置。

内核负责监听代理端口、解析配置、匹配规则、建立出站连接，并处理 DNS 等网络逻辑。图形客户端负责订阅导入、策略组选择、系统代理开关、后台服务和日志展示。配置文件则把代理节点、策略组、规则与 DNS 设置交给内核执行。

原版 Clash、Meta 与 mihomo 的关系

原版 Clash：生态的起点

原版 Clash 通常指 Dreamacro/Clash 项目的开源内核，以 Go 编写，形成了广泛使用的 YAML 配置结构与控制接口。原项目在 2023 年 11 月停止公开维护后，历史程序和配置仍然存在，但不能把旧版安装包当作持续获得修复的当前版本。

还要区分历史上的 Clash Premium。它并不是“所有开源 Clash 内核”的统称，也不是 mihomo 的旧名称。旧教程中的部分功能曾以 Premium 为前提，不能仅凭一个配置字段就认定原版开源内核一定支持。

Clash Meta：在原版基础上的扩展分支

Clash Meta 基于原版 Clash 的代码发展，扩展了协议、DNS 和路由等能力。旧文档里的“Meta 内核”“Clash.Meta”通常是在指这条项目路线，而不是一种单独的订阅格式。某份订阅标注“需要 Meta”，实际含义往往是配置使用了原版旧内核没有实现的功能。

mihomo：Meta 项目的后续名称

Clash Meta 后来更名为 mihomo，目前常见项目路径为 MetaCubeX/mihomo。因此，Meta 与 mihomo 不是两套互不相干、需要按顺序同时启动的内核。旧名称仍可能出现在客户端菜单、订阅说明、文件名或教程中，识别时应结合仓库地址与版本输出。

内核项目演进（简化）
Dreamacro/Clash
└─ Clash.Meta（扩展分支）
   └─ mihomo（后续名称，MetaCubeX/mihomo）

调用关系（不是代码继承关系）
Clash Verge Rev 等图形客户端
├─ 管理订阅与本地配置
├─ 启动、停止或重载 mihomo
└─ 通过控制接口读取状态、切换策略

这张关系图表达的是项目演进和运行分工，不表示不同分支的每个功能都一一对应。判断配置能否使用，应查当前内核版本支持的字段与协议，而不是只看客户端名称里有没有“Clash”。

Verge Rev 等图形客户端怎样调用内核

Clash Verge Rev 是桌面图形客户端项目，采用 Tauri 技术栈，与 mihomo 是独立项目。安装包通常会配套内核，客户端负责生成运行配置、启动内核进程，再通过控制接口展示代理组、连接记录和日志。客户端版本与内核版本是两套编号，升级其中一个不等于另一个必然同步升级。

1. 导入配置：客户端保存订阅地址或本地 YAML，并读取配置内容。
2. 整理运行参数：客户端可能通过覆写、合并配置或脚本，调整端口、DNS 和规则。
3. 启动内核：内核读取最终生成的配置，建立本地监听并加载规则。
4. 界面控制：客户端调用控制接口，完成策略切换、配置重载与日志展示。
5. 系统集成：客户端按需设置系统代理，或通过服务与权限机制支持 TUN。

图形界面、网页面板、内核不是同一对象

网页控制面板主要通过控制接口管理已经运行的内核，通常不负责完整的桌面安装、开机启动与权限服务。只有一个面板页面，并不代表本机已经启动代理内核。相反，内核在命令行运行时，也可以没有桌面窗口。

历史客户端也要分别判断。Clash for Windows、原 Clash Verge、Clash Verge Rev 并不是同一项目的三个版本号。名称相近不代表维护团队相同；能够调用开源内核，也不自动意味着该图形客户端的全部代码采用同一许可证。

配置兼容性：重点检查四个位置

多数配置沿用 proxies、proxy-groups、rules 这些顶层结构，但“能解析 YAML”不等于“能执行全部配置”。旧内核遇到新协议、不同规则语法或新增 DNS 字段，可能报错，也可能出现与预期不同的行为。

• 节点类型：例如 VLESS、Hysteria2、TUIC 等能力需要核对 mihomo 的具体版本；不能据此推断原版旧内核支持。
• 规则与规则集：rule-providers 的格式、行为类型与文件内容必须匹配。域名列表不能直接当作完整规则列表使用。
• DNS 设置：fake-ip、上游解析与路由相关设置应按当前内核文档核对，避免整段复制旧教程。
• 客户端覆写：编辑订阅原文后没有生效，可能是最终运行配置被覆写，也可能是订阅更新覆盖了修改。

端口示例：代理端口与控制端口不能混用

下面是便于辨认用途的配置片段，不是可独立连接的完整配置，也不代表所有客户端的出厂默认值。示例中 7890 用于 HTTP 与 SOCKS 代理，9090 用于控制接口，二者用途不同。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

浏览器或命令行程序应连接代理端口，而不是把 9090 填成上网代理。控制接口建议限制在本机；如需远程控制，应另行配置认证和访问限制。不要为了让界面连接成功就直接向局域网或公网开放接口。

系统代理与 TUN：分别看界面和内核

系统代理通常把操作系统的代理设置指向本地监听端口。遵循该设置的浏览器和应用会通过代理发起请求，但并非每个应用都会读取系统代理。规则模式则决定进入内核的连接如何分流；它本身不会强制所有程序接入。

TUN 通过虚拟网络接口与路由接管流量，还涉及 DNS、权限和系统网络环境。mihomo 提供相关内核能力，客户端负责开关、服务安装和权限衔接。界面里出现 TUN 按钮，并不能单独证明服务、路由和 DNS 都已正常工作。

第一次验证建议先使用系统代理，确认订阅、策略组和代理端口正常，再按应用需求启用 TUN。这样能把节点连接问题与系统接管问题分开，避免同时改动多个变量。

客户端选型与版本确认步骤

先记录两套版本，再比较功能

以 Clash Verge Rev 为例，可先在「设置」→「关于」查看客户端版本，再在「设置」中的内核相关区域或启动日志确认内核名称与版本。具体入口会随发行版调整，若没有独立的内核版本入口，以该版本的日志和项目说明为准。需要记录的是完整版本号，而不是笼统写“最新版”。

如果已定位到实际使用的内核可执行文件，可以在终端读取其版本。Windows PowerShell 的示例命令如下；文件名以安装包实际名称为准，不要误把图形客户端主程序当作内核执行。

# 在实际内核文件所在目录执行
.\mihomo.exe -v

# 对准备使用的 YAML 做配置检查
.\mihomo.exe -t -f .\config.yaml

配置检查能发现语法与部分字段错误，但不等于节点已经连通，也不等于系统代理或 TUN 已接管流量。若配置依赖相对路径、外部规则集或提供器文件，检查时还要使用对应的工作目录与配套文件。

按使用场景确定选择顺序

1. 桌面日常使用：先确认系统与处理器架构，再选仍在维护、能够清楚展示内核状态的图形客户端。
2. 配置含较新协议：先确认所需 mihomo 版本，再核对客户端实际配套的版本，不能只比较界面功能。
3. 需要 TUN：核对当前系统的服务安装、管理员权限与已知网络兼容问题，保留关闭 TUN 的恢复路径。
4. 服务器或自动化：可以直接运行内核并独立管理配置、进程与控制接口，不必为此安装完整桌面界面。
5. 迁移历史配置：先在新客户端中验证配置解析、策略选择和 DNS，再迁移开机启动与系统接管设置。

核对开源信息时，也要分别查看内核与客户端仓库的许可证。mihomo 使用 GPL-3.0；这不能替代对某个图形客户端、安装包附带组件及其发行说明的独立核对。项目名、仓库地址、客户端版本和内核版本应当对应起来。

迁移后的最小验证清单

完成安装或替换后，先用一份已知可用的配置做小范围验证。不要立即同时开启系统代理、TUN、复杂覆写与自动切换；一次只增加一项设置，日志才容易定位。

• 确认内核已启动，实际监听端口与应用填写的端口一致，例如示例中的 127.0.0.1:7890。
• 确认订阅解析完成，策略组中的节点名称存在，没有引用已删除的策略。
• 在规则模式下发起一次访问，查看连接记录中的命中规则与最终出站链路。
• 检查本地规则和覆写是否进入最终运行配置，再执行订阅更新，确认修改仍按预期保留。
• 最后测试重启客户端后的配置恢复，以及按需启用的系统代理或 TUN 行为。

需要逐步完成安装与导入，可继续查看使用指南；遇到端口、订阅或系统接管问题，可查阅帮助中心。不熟悉策略组和规则集等术语时，可先阅读名词解释。