Clash 内核、mihomo 与各家客户端的关系图谱:开源生态一文理清

先分清三层：内核、客户端与配置

Clash 不是一个能概括所有安装包的单一产品名。原版 Clash 是代理内核；mihomo 是从 Clash Meta 发展而来的内核项目；Clash Verge Rev、FlClash 等则是围绕内核构建的图形客户端。判断一项功能是否可用，需要同时看客户端版本、实际运行的内核，以及最终加载的配置。

最直接的区分方法是看工作边界：内核解析 YAML、处理连接、执行 DNS 与分流规则；客户端管理订阅、显示策略组、切换系统代理，并负责内核进程和服务的启动；订阅提供方则交付节点参数或完整配置。三者相关，但不是同一个维护主体。

层级	典型对象	主要职责
代理内核	Clash、mihomo	监听端口、解析配置、匹配规则、连接上游
图形客户端	Clash Verge Rev、FlClash	配置导入、策略选择、系统集成、日志展示
配置与订阅	YAML 文件、订阅地址	提供节点、策略组、规则与更新入口

项目演进：原版 Clash、Clash Meta 与 mihomo

原版内核停更，不等于整个生态停止

2023 年 11 月前后，原版 Clash 项目停止公开维护。此前生态中还存在 Clash Premium 这一闭源分支，其功能集与开源原版并不完全相同。旧教程只写“Clash 支持 TUN”时，往往省略了具体分支和平台条件，不能直接套用到任意旧版内核。

停止维护意味着后续协议适配、系统兼容和问题修复不能再依赖原项目持续交付。旧程序可能仍能运行，但“能够启动”和“适合继续作为日常网络组件”是两件事。迁移时更应关注当前维护状态，而不是只比较安装包名称是否熟悉。

Clash Meta 是 mihomo 的旧项目名

Clash Meta 源自 Clash 生态的分支开发，后来更名为 mihomo。旧文档里的“Meta 内核”和新文档里的“mihomo 内核”通常指向同一条项目演进线，而不是需要同时安装的两个组件。项目更名也不代表所有旧字段、旧二进制名称和客户端界面标签会立即统一。

mihomo 延续了 Clash 风格的 YAML 配置与控制接口，并扩展协议和路由能力。不过，“接力”描述的是生态维护与功能发展，不能理解为原版团队的官方交接，也不能推导出新旧配置百分之百兼容。

项目演进线：
原版 Clash ── 分支开发 ── Clash Meta ── 更名 ── mihomo

集成关系：
Clash Verge Rev ── 管理并调用 ── mihomo
FlClash         ── 集成并调用 ── mihomo

数据输入：
订阅或本地 YAML ── 客户端处理 ── 运行时配置 ── 内核加载

这张图表达项目与组件关系，不代表客户端共享同一套界面代码。两款客户端即使使用相近的内核，也可能采用不同的配置合并流程、服务管理方式与平台适配逻辑。

客户端负责什么：Verge Rev 与 FlClash 的边界

Clash Verge Rev：桌面界面与系统集成

Clash Verge Rev 是面向 Windows、macOS 和 Linux 的桌面客户端，采用 mihomo 内核。订阅列表、托盘菜单、策略组选择、连接记录等属于客户端交互层；连接最终走哪个代理、某条规则是否匹配，则由运行中的内核执行。

客户端的“服务模式”通常用于让后台组件以所需权限管理内核或网络功能。它不是一种代理协议，也不等于打开后所有流量就自动进入代理。是否接管流量，还要看系统代理、TUN、路由与应用本身的连接方式。

FlClash：跨平台界面与移动端集成

FlClash 是基于 Flutter 构建、使用 mihomo 内核的客户端项目，覆盖桌面和 Android 等平台。Android 上通过系统 VPN 接口接管流量，与桌面修改系统代理的工作方式不同。界面中的启动按钮可能看起来相似，底层需要的系统授权却不一样。

遇到 FlClash、FlClashs 等相近名称时，应分别确认项目来源、维护者和发布记录，不要仅凭名称判断它们是同一个项目。平台覆盖也应以具体项目的发行清单为准，不能把一款软件的功能说明套给同名分支。

旧客户端名称不能代替内核信息

Clash for Windows：已停止维护。历史安装包可能包含不同内核，不能把它与当前 mihomo 客户端画等号。
Clash for Android：原项目已停止维护。Android VPN 权限只是流量接入条件，不会自动补齐旧内核缺失的协议能力。
其他桌面封装：先查看项目说明中的内核类型，再确认当前安装包实际携带的内核版本，不能只看名称里是否含有 Clash。

选型时可以先看客户端对比，再按系统进入下载页。需要的是“当前平台可运行、内核支持配置、系统集成方式合适”这三个条件同时成立。

一份 YAML 如何从订阅进入内核

订阅地址是配置来源，不是代理协议。地址返回的内容可能是完整 YAML，也可能是节点集合或其他格式。客户端能否直接导入，取决于它支持的输入格式；内核能否加载，则取决于生成后的配置是否符合该内核的字段和协议要求。

获取内容：客户端下载订阅，或读取本地 YAML 文件。
处理配置：客户端可能应用覆写、合并、脚本或全局设置，生成实际运行文件。
加载内核：内核读取最终配置，建立监听器，初始化代理、DNS 和规则。
接入流量：应用连接代理端口，或由 TUN 等入口将流量送入内核。
执行分流：规则模式下，内核按规则顺序匹配，并使用目标策略处理连接。

下面是用于说明字段归属的最小配置示例，没有远程代理节点。所有正常流量最终直连，因此它不能用来证明远程代理可用。端口 7890 和 9090 是示例值，并非每个客户端的固定默认值。

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

external-controller: 127.0.0.1:9090
secret: "local-doc-demo-rotate-before-use"

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Route

mixed-port 是 HTTP 与 SOCKS 混合代理入口。应用流量可以从这里进入内核。
external-controller 是控制 API 的监听地址，用于查询状态和修改选择，不是供浏览器设置的代理端口。
proxy-groups 定义策略组；客户端展示选项，内核保存并执行当前选择。
rules 定义匹配顺序。末尾的 MATCH 承接此前未命中的连接。

如果订阅原文中的端口是 7890，客户端最终却监听其他端口，先检查客户端的全局设置或覆写。排障应查看运行时配置，而不是反复修改会在下次更新时被覆盖的订阅文件。字段含义可对照YAML 手册。

系统代理、TUN 与协议支持分别由谁决定

系统代理是应用入口，不是内核能力升级

打开系统代理后，遵循系统代理设置的应用才会向指定端口发送请求。自行建立直连的程序、不读取系统代理的命令行工具，以及部分游戏流量，不一定被接管。此时更换图形界面的主题或重导入同一份订阅，通常无法改变应用的联网方式。

TUN 依赖内核能力，也依赖客户端和系统权限

TUN 通过虚拟网络接口接入 IP 流量。内核需要支持相应功能；客户端还需要正确创建接口、管理权限和路由，并协调 DNS。Windows 服务权限、Linux 网络管理权限、Android VPN 授权都属于这条链路中的平台条件。

TUN 也不等于“所有连接都走远程节点”。流量进入内核后仍可能按规则选择 DIRECT，并可能受路由排除、应用分流设置影响。需要同时核对接管范围和规则结果，而不是只看 TUN 开关是否亮起。

新协议通常看内核，配置入口还要看客户端

某个节点类型是否可用，首先取决于内核是否支持，以及节点参数是否正确。旧内核遇到新协议时，可能报告不支持的代理类型或配置加载失败。升级图形客户端有时会一并更新内核，但客户端版本号与内核版本号不是同一套编号。

反过来，内核支持某字段，也不保证客户端编辑器已经提供对应按钮。部分功能需要写入 YAML 或通过覆写加入。若界面保存时会重写配置，还要确认自定义字段不会被删除。

选型与排障：按组件逐层确认

遇到“同一份订阅在另一款客户端能用”的情况，不要立即归因于节点质量。两边可能使用不同内核、不同覆写、不同 DNS 设置，甚至根本没有采用同一种流量入口。按下面顺序比对，更容易找到差异。

记录两个版本：分别记录客户端版本与内核版本。可从“关于”、内核管理界面或启动日志查找；具体菜单名称以当前发行版为准。
检查加载结果：先找配置解析错误、未知代理类型、策略名称不存在等信息。加载尚未成功时，测试出口 IP 没有诊断价值。
核对入口：确认当前使用系统代理还是 TUN。若用显式代理测试，端口必须对应实际监听值，而不是照抄教程。
核对策略：查看连接日志中的命中规则、策略组与最终节点。规则指向直连时，出口保持本地地址是预期结果。
最后比较 DNS 与网络：配置相同但解析结果、IPv6 路由或上游网络不同，也会导致访问差异。

例如，实际混合端口是 7890 时，可以在终端显式指定代理，排除应用是否遵循系统代理这一变量。Windows 下若 curl 被解释为其他命令，可使用 curl.exe。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

这个命令只检查经指定 HTTP 代理入口发起一次请求的结果，不代表 TUN 已接管其他应用，也不能单独证明使用了远程节点。应同步查看内核连接记录；若命中了 DIRECT，请求依然通过本地网络直连目标。

迁移旧配置：保留必要字段，逐项恢复功能

从已停止维护的客户端迁移到 mihomo 客户端时，建议先备份原配置与自定义规则，再用有效订阅建立最小可用连接。不要直接覆盖新客户端的全部运行目录，也不要把旧服务文件和新内核二进制混合使用。

先确认协议：检查订阅输出是否面向当前内核，节点名称与策略组引用是否一致。
再迁移规则：先恢复少量明确规则，检查命中结果，再加入规则集与复杂分流。
最后迁移 DNS 和 TUN：这两部分与操作系统、局域网环境关系较大，不宜盲目照搬旧配置。
避免双重接管：测试新客户端时退出旧客户端，并确认旧服务没有继续占用代理端口或维护虚拟接口。

生态选型的核心不是寻找一个名字完全相同的替代品，而是把职责拆开：用内核能力判断协议与配置兼容性，用客户端功能判断平台集成体验，用运行时配置与日志判断实际行为。分清这三层后，项目更名、客户端分支和配置迁移就能放到同一套检查流程中处理。