Clash 开源生态全景：mihomo 内核与各图形客户端的分工关系

内核、客户端与配置的三层关系

Clash 生态中的名称并不处在同一层：mihomo 是处理网络流量的内核，Clash Verge Rev、FlClash 是提供操作界面的客户端，YAML 则是描述节点、策略组和规则的配置格式。选择软件之前，先区分这三层，才能判断“某个功能是否支持”应该查内核文档，还是查客户端设置。

内核可以脱离桌面窗口运行，例如在服务器上读取 YAML 文件并开放本地代理端口。客户端则负责把导入配置、启动进程、修改系统设置等动作包装成按钮。二者经常一起安装，因此用户容易把界面的版本号误当成内核版本号。

原版 Clash、Clash Meta 与 mihomo 的沿革

2023 年 11 月，原版 Clash 及多个相关项目的公开仓库发生删除、归档等变化，原有上游维护链路中断。历史资料中的开源 Clash、Clash Premium 和图形客户端也不是同一个发布对象：Clash Premium 是曾经提供额外功能的闭源内核分支，Clash for Windows 则是客户端。

Clash Meta 是基于 Clash 发展出来的开源分支，后来更名为 mihomo。因此，旧教程中的“Meta 内核”和新文档中的“mihomo 内核”存在项目沿革关系，而不是两个毫无关联的配置体系。部分应用名、仓库名和订阅入口仍然保留 Meta 字样，名称未同步变化并不直接说明其内部使用哪一版内核。

配置兼容需要逐项判断

• 基础结构：proxies、proxy-groups、rules 等字段延续了 Clash 体系的组织方式，但这不等于所有版本都支持所有子字段。
• 新增协议：例如 type: vless 或 type: hysteria2，需要实际内核具备对应实现，不能仅凭客户端名称包含 Clash 判断。
• 扩展功能：嗅探、DNS 策略和 TUN 相关字段可能随着版本演进而变化，应对照正在运行的内核文档。
• 其他生态：sing-box JSON 不属于 Clash YAML。客户端即使界面相似，也不能据此直接互换配置文件。

将 mihomo 称为“接棒者”，描述的是社区使用与功能发展的延续，不代表它是原版项目发布的官方升级包。历史客户端也不会因为更换一个订阅地址，就自动获得新内核的协议支持。

Verge Rev、FlClash 与 Android 客户端的分工

下面的对照聚焦项目定位，不用一个静态版本号代替持续变化的发布状态。平台是否有可安装包、包内使用哪个内核，应以对应项目具体发行说明为准；同一项目的不同发行渠道也可能采用不同更新节奏。

桌面客户端：系统集成是主要差异

Verge Rev 与 FlClash 即使使用接近的 mihomo 版本，体验仍可能不同。开机启动、托盘菜单、系统代理恢复、服务安装、配置覆写和错误提示，主要属于客户端层。比较时，应观察“退出程序后代理是否恢复”“订阅更新后本地规则是否保留”等具体行为，而不只比较节点列表的布局。

Android 客户端：VPN 接管与后台约束

Clash Meta for Android 这类应用通常通过 Android 的 VPN 接口接管流量，需要用户授权。这个 VPN 接口描述的是系统接管机制，不代表订阅服务一定使用传统 VPN 协议。Android 通常只允许一个普通 VPN 服务处于活动状态，因此它可能与另一款 VPN 型防火墙或过滤应用产生占用冲突。

Android 的省电限制、后台进程管理和按应用分流也属于选型条件。桌面能正常运行的 YAML，在手机上仍可能需要调整监听地址、端口或路由相关设置。客户端的跨平台支持，不能推导为系统行为完全一致。

流量路径：系统代理、控制接口与 TUN

理解流量路径，比记住应用图标更有助于定位问题。常见的系统代理路径是“应用遵循系统代理设置 → 本机代理监听端口 → 内核匹配规则 → 节点或直连出口”。不遵循系统代理设置的程序，可能根本没有进入这条路径。

三个接口不能混用

• 代理监听端口：供浏览器、命令行工具等发送代理请求，例如示例中的 127.0.0.1:7890。
• 控制接口：供客户端或面板查询状态、切换策略，例如 127.0.0.1:9090；它不是浏览器的上网代理端口。
• TUN 虚拟网卡：在系统网络层接收被路由过来的流量，实际覆盖范围取决于路由、排除项、DNS 与权限配置。

以下片段仅用于说明端口与控制面的分工，不是一份含节点的完整配置。端口是示例值，不代表每个客户端的默认值；图形客户端还可能在启动时改写这些字段。

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

mixed-port 可在同一监听端口接受 HTTP 与 SOCKS 代理请求。mode: rule 表示按规则处理流量，并不意味着系统中每个程序都会自动使用代理。控制接口具有管理能力，应保留在可信范围；确需远程访问时，还要配置认证与网络访问限制。

订阅到运行配置：客户端还会处理哪些内容

订阅下载成功，只说明客户端取得了远程内容。随后还需要解析格式、应用本地合并或覆写、生成运行配置，再交给内核加载。订阅源文件、客户端编辑器里展示的文件、内核最终使用的文件，可能并不完全相同。

两类远程更新需要分开看

1. 完整配置订阅：远程 YAML 可以同时包含节点、策略组与规则。更新时，客户端如何保留本地修改取决于其配置管理机制。
2. 节点提供者：proxy-providers 引用的远程资源主要提供节点，外层配置仍需定义策略组以及如何使用这些节点。
3. 规则提供者：rule-providers 提供规则集，不能替代节点订阅；规则集还需要由规则条目引用。

例如，策略组引用了名为 工作出口 的节点，但订阅更新后该名称消失，配置可能加载失败或出现选择异常。这属于配置引用关系问题，并不是客户端窗口渲染故障。排查时应查看生成后的配置和内核报错行，而不是反复重装应用。

迁移客户端时，优先保存订阅地址、本地规则和覆写逻辑，而不是只复制应用内部数据库。尤其是脚本覆写，不同客户端暴露的对象与执行流程可能不同；一个客户端可执行的脚本，不能直接视为 mihomo 内核的通用功能。字段细节可对照YAML 配置手册。

客户端选型与迁移核对步骤

选型可以从操作系统、所需协议和接管方式三项开始。只需要浏览器代理的桌面用户，可以先验证系统代理路径；需要处理更多应用流量时，再检查 TUN 与服务权限。Android 用户则应优先确认 VPN 授权、后台运行和按应用分流是否符合实际使用场景。

1. 确认平台与架构。区分 Windows、macOS、Linux 与 Android，再核对 x64、ARM64 等安装包架构；Apple Silicon 与 Intel Mac 不应只凭文件名中的 macOS 混选。
2. 记录两个版本。从客户端的关于信息、内核设置或启动日志分别记录客户端版本和 mihomo 版本。界面入口随客户端版本变化，应以实际界面为准。
3. 先导入，再检查日志。先确认 YAML 解析成功、节点和策略组存在，再开启系统代理或 TUN，避免把配置错误误判为网络故障。
4. 只运行一套接管链路。迁移时先关闭旧客户端的系统代理、TUN 和后台服务，再启动新客户端，减少端口占用与路由冲突。
5. 验证真实请求。观察连接页中的进程、目标地址、命中规则和出口策略。节点延迟测试成功，只能说明相应探测请求成功，不能证明全部应用路径正常。
6. 检查更新后的行为。手动更新一次订阅，确认本地规则仍存在、策略组引用有效，并确认运行配置使用了预期的监听端口。

若两个客户端设置了同一个 7890 监听端口，后启动的一方可能报告地址占用；若旧客户端退出后系统仍指向 127.0.0.1:7890，浏览器则可能无法连接。这两种情况都与远端节点是否在线无直接关系。

常见判断：名称相近不代表能力相同

装了 mihomo，还需要图形客户端吗？

不一定。熟悉命令行、服务管理与配置文件的用户可以独立运行内核。需要托盘操作、订阅管理和系统设置集成时，图形客户端更便于日常使用。两种方式使用相同内核时，协议能力主要取决于内核版本，系统集成能力则取决于客户端实现。

旧 Clash YAML 能直接放进新客户端吗？

许多基础配置能够沿用，但应先加载验证。文件里的协议类型、外部资源路径、规则目标名称，以及客户端注入的 DNS 或 TUN 设置都需要检查。旧文件可解析，也不代表其网络策略适合当前设备。

选择界面还是选择内核？

先用内核能力确定协议与规则需求，再用客户端能力确定操作方式。具体比较平台覆盖、配置覆写、后台服务与更新机制，可继续阅读客户端横向评测；第一次使用则按快速上手完成导入与验证。把内核、界面、配置三层分开记录，后续升级和故障定位会更明确。