Clash、mihomo 与 Clash Verge Rev 是什么关系：内核、客户端与分支脉络梳理

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

搜索 Clash 电脑版时，结果里经常同时出现 Clash、Clash Meta、mihomo、Clash Verge Rev 和 Clash for Windows。这些名称并不处于同一层级：有的是处理网络连接的内核，有的是提供窗口与托盘菜单的客户端，还有一些只是配置格式的称呼。先区分它们，才能判断应下载什么，以及发生故障后该查看哪一层。

• 内核：读取配置，监听本地代理端口，执行 DNS 解析、规则匹配、策略组选路与协议连接。即使没有图形窗口，也可以通过命令行运行。
• 图形客户端：负责订阅导入、配置切换、系统代理开关、内核进程管理、日志展示，以及部分需要权限的系统集成。
• 配置与订阅：向内核提供节点、策略组、分流规则和 DNS 参数。订阅是获取配置或节点数据的一种方式，不等同于客户端，也不自动代表某种内核。

例如，浏览器把请求发给本机 127.0.0.1:7890，接收请求并按规则转发的是内核；点击窗口里的「系统代理」开关，是客户端在修改操作系统代理设置。这里的 7890 只是常见配置示例，实际端口应以正在运行的客户端设置为准。

项目脉络：原版 Clash、Clash Meta 与 mihomo

原版 Clash 与 Premium 的区别

原版 Clash 通常指 Dreamacro/Clash 项目的 Go 语言代理内核。围绕它形成了 YAML 配置、策略组、规则列表与控制 API 等使用习惯，许多客户端因兼容这些接口而被统称为 Clash 客户端。原版项目在 2023 年 11 月停止公开维护，不应把旧版本号当成今天仍在更新的产品线。

历史上还存在 Clash Premium。它与开源版并非完全相同的功能集合，Premium 曾提供 TUN、规则提供器等扩展能力。查阅旧教程时，看到“仅 Premium 支持”的提示，需要结合当时的内核判断，不能直接推导为今天的 mihomo 不支持，也不能反过来认为旧版 Clash 一定支持。

Clash Meta 后续以 mihomo 名称发展

Clash Meta 是沿 Clash 技术路线扩展的内核分支，后续以 mihomo 名称继续发展，项目仓库标识为 MetaCubeX/mihomo。因此，“Meta 内核”和“mihomo 内核”在许多教程里指向同一条演进路线，不是必须同时安装的两套代理程序。

mihomo 保留了大量 Clash 配置习惯，同时增加和调整了协议、DNS、规则与 TUN 等能力。兼容并不意味着任意配置都能跨内核直接使用：新字段可能无法被旧内核识别，某种协议或规则行为也可能只在特定版本中实现。判断依据应是目标内核的文档、发布说明和启动日志，而不是配置文件名里有没有“Clash”。

原版 Clash ── 衍生与扩展路线 ── Clash Meta → mihomo
                                                  ↑
                                      Clash Verge Rev 调用

原版 Clash Verge ── 客户端延续分支 ── Clash Verge Rev

这张关系图区分的是代码与功能路线。Clash Verge Rev 的客户端分支关系来自 Clash Verge，不是把 mihomo 改名后加了一个窗口；mihomo 与客户端也各自有独立的版本和发布节奏。

Clash Verge Rev、Clash for Windows 等客户端怎么区分

Clash Verge Rev 延续了 Clash Verge 的客户端路线，使用 mihomo 处理代理流量。它的价值主要体现在桌面管理：把内核配置、策略组选择和系统集成集中到窗口中。免费、开源与多平台是项目属性，但不能代替对操作系统版本、处理器架构和具体功能的核对。

Clash for Windows 则属于已经停止维护的历史客户端。它的名称中虽然带 Windows，历史发行也不只面向 Windows；更重要的是，它不是所有 Clash 电脑版的统称。旧教程里的 General、Profiles、Proxies 页面，分别大致对应常规设置、配置管理和代理策略页面，不能要求其他客户端保留相同菜单。

客户端版本不等于内核版本

排查问题时至少记录三项：客户端名称及版本、内核名称及版本、操作系统与架构。先在「设置」中找「关于」或版本信息，再查看内核设置或启动日志；不同发行版的菜单文字会变化。只说“Clash 已更新”无法判断更新的是界面、内核，还是仅仅刷新了订阅。

订阅能否通用：看最终交给内核的配置

“Clash 订阅”可能返回完整 YAML 配置，也可能仅返回节点列表，甚至可能因为链接失效而返回登录网页。客户端能保存链接，并不等于内核已经接受了内容。完整配置一般包含 proxies、proxy-groups、rules 等字段；通过 proxy-providers 引用的节点提供器文件，则不必具备完整配置的全部结构。

1. 先确认订阅输出类型。服务方如果提供多个格式，应选与目标内核兼容的选项。浏览器看到一段 Base64 文本或 HTML 页面时，不要把它直接当作完整 YAML。
2. 再核对协议和字段。订阅使用新协议、新的 DNS 字段或 mihomo 扩展规则时，旧版内核可能直接报解析错误，也可能在连接阶段才失败。
3. 最后检查客户端合并结果。客户端的覆写、合并配置或脚本可能改变端口、DNS 与规则。订阅原文正确，不代表最终运行的配置仍然相同。

遇到 unsupported proxy type 一类提示，优先核对节点类型与内核支持范围；遇到 YAML 解析错误，先检查缩进与内容格式。盲目切换客户端，可能只是把同一份错误配置交给另一套界面。

端口、系统代理与 TUN 分别由谁负责

用最小配置理解本地入口

下面是用于说明字段关系的最小配置，不含远端代理节点，所有匹配流量都直连。它不是可替代订阅的代理方案，也不建议直接覆盖正在使用的配置。

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

rules:
  - MATCH,DIRECT

• mixed-port: 7890：让内核在同一端口接受 HTTP 与 SOCKS 代理连接；访问地址通常写作 127.0.0.1:7890。
• allow-lan: false：不向局域网其他设备开放代理入口；它与“允许本机应用使用代理”不是同一个开关。
• mode: rule：按规则决定策略。模式切换本身不会自动产生远端节点。
• MATCH,DIRECT：兜底规则走直连。实际订阅通常会把部分请求交给策略组，而策略组再选择节点。

系统代理开关不保证全部应用接入

客户端打开「系统代理」后，通常会把系统的 HTTP 代理地址指向内核入口。遵循系统代理的应用才会使用这个入口；自行管理网络连接的程序、部分游戏以及某些 UDP 流量，不一定跟随该设置。端口已监听、系统代理已打开和某个程序已走代理，是三个需要分别确认的事实。

TUN 模式则由内核配合虚拟网络接口和路由设置接入流量，客户端负责权限、服务和开关管理。它可能需要管理员权限或已安装的服务组件。TUN 并非“全局模式”的另一个名字：TUN 决定流量如何进入内核，规则模式或全局模式决定进入后如何选路，两者可以分别设置。

遇到 TUN 故障，应同时查看客户端服务状态、内核启动日志、DNS 与路由配置。仅替换一个同名内核文件，未必能解决权限或虚拟网卡问题，反而可能破坏客户端与内核之间的兼容关系。

实际选型与迁移：按四步核对

1. 先定系统和架构。Windows 常见 x64 与 ARM64，macOS 需区分 Apple 芯片与 Intel。先在系统信息里确认，再选择安装包；不要仅凭文件名中有 Windows 或 macOS 就下载。
2. 再定使用方式。需要托盘、配置管理和系统代理开关时，选择图形客户端；在服务器或已有进程管理环境中使用，才考虑直接运行 mihomo。
3. 确认维护与依赖。查看客户端近期发布说明及其集成内核信息，重点核对自己的协议、TUN 和 DNS 需求。新客户端并不保证内核永远自动保持最新。
4. 迁移时一次只启用一套。保留原配置备份，退出旧客户端并关闭它的系统代理、TUN，再启动新客户端，防止端口和路由互相干扰。

导入成功后，怎样确认接入链路

先在配置页启用目标配置，再到代理页确认策略组选择，最后检查日志有没有端口占用或解析失败。若实际混合端口是 7890，Windows 可在终端使用以下命令显式指定 HTTP 代理入口：

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

这条命令不依赖浏览器是否读取系统代理，但仍需目标站点可达。出现响应头只能说明这次请求通过指定入口完成，不能单凭它证明使用了远端节点；还应在客户端连接页查看目标域名、命中规则和所选策略链。若提示无法连接本机端口，先确认端口与内核状态，而不是立即更换订阅。

最终选择可以归纳为两句：桌面日常使用优先看客户端的系统集成与维护状态；配置能力和网络行为则看实际运行的内核。把“界面叫什么”与“内核支持什么”分开记录，后续查教程、升级和排障都会更明确。需要继续核对字段，可查阅本站的配置进阶；首次使用则按使用指南完成导入与系统代理设置。