Clash、mihomo 与 Clash Verge Rev 是什么关系:开源项目谱系梳理
从原版内核归档到 mihomo 接棒,再到各图形客户端的分工,按内核层与界面层理清项目之间的继承关系与选型依据。
先分清内核、客户端与订阅
搜索 Clash Windows 客户端时,常会同时看到 Clash、Clash Meta、mihomo、Clash Verge Rev 和 Clash for Windows。这些名称不在同一个层级。先确认哪个项目负责处理网络连接,哪个项目负责提供操作界面,再判断配置是否兼容,能避免把旧教程里的按钮直接套到新客户端上。
| 层级 | 典型名称 | 实际职责 |
|---|---|---|
| 代理内核 | Clash、mihomo | 监听代理端口、解析 DNS、匹配规则、建立出站连接。 |
| 图形客户端 | Clash Verge Rev | 管理配置、切换代理组、展示日志,并管理内核进程与系统集成。 |
| 配置内容 | 订阅返回的 YAML | 提供节点、代理组、规则,以及可能包含的 DNS 等设置。 |
可以把一次访问拆成三个环节:应用把连接交给本地代理,内核按照配置选择出站,客户端把运行状态显示出来。客户端并不提供可用节点;下载安装完成后,仍需导入自己有权使用的订阅或手动配置。
项目谱系:Clash 到 mihomo
原版 Clash 与 Clash Premium
原版 Clash 是 Dreamacro 发起的 Go 语言代理内核。许多图形客户端通过启动内核进程、调用控制接口来管理它。Clash Premium 则是同一时期的另一条内核发行线,包含一些原版开源内核没有的功能,但其完整源码并未开放。阅读历史教程时,不能把 Premium 的功能表直接当成原版开源 Clash 的功能表。
2023 年 11 月前后,原版项目停止公开维护,相关仓库和发行入口发生变化。网络上常把这一阶段统称为“原版归档”,但实际还涉及仓库删除、留存镜像与第三方备份,并不是所有入口都只是设置成只读。旧程序可能仍可运行,停止维护却意味着不能继续依赖原维护者提供兼容性修复与安全更新。
Clash.Meta 与 mihomo
Clash.Meta 是从 Clash 生态发展出来的内核分支,后来更名为 mihomo,由 MetaCubeX 社区维护。旧文档中的 Clash Meta、Clash.Meta,以及部分程序文件名中的 Meta,往往指向这条项目谱系。更名不等于突然换成完全无关的配置体系,但具体功能仍取决于所用内核版本。
mihomo 延续了 Clash 风格的 YAML 配置、代理组与规则机制,并继续扩展协议和网络处理能力。例如,一份包含 type: hysteria2 节点的配置,需要内核支持对应协议;仅仅把旧客户端界面的名称改成“Meta”并不能增加协议支持。遇到 unsupported proxy type 一类错误,应先核对内核能力,而不是反复更换订阅地址。
- 历史来源:Clash 是原始内核项目,Clash.Meta 是分支发展路径之一。
- 名称延续:mihomo 是 Clash.Meta 后续使用的项目名称,旧称仍可能出现在教程和设置里。
- 维护关系:社区延续不是原作者恢复维护,也不意味着所有含 Clash 名称的软件都由同一团队发布。
Clash Verge Rev 与内核的分工
Clash Verge Rev 是图形客户端,延续了 Clash Verge 的界面项目路线,使用 mihomo 处理代理连接。它不是 mihomo 的另一个名字,也不是原版 Clash 的“Windows 安装版”。安装包通常同时提供界面程序及配套内核,因此用户可以在一个窗口里完成导入配置、启动代理和查看日志。
在 Clash Verge Rev 中,可按侧栏「配置」→ 导入订阅、「代理」→ 选择代理组、「日志」→ 查看连接错误的顺序操作。不同版本的按钮文字和设置分组可能调整,但这些页面的职责比较稳定。需要启用系统代理或 TUN 模式时,再进入「设置」检查相应开关,不要把代理页里的节点选择当作流量接管开关。
| 操作或现象 | 主要关联层 | 优先检查 |
|---|---|---|
| 订阅导入按钮没有响应 | 客户端 | 界面提示、订阅请求、配置解析错误。 |
| 节点协议不被识别 | 内核 | 内核版本与对应协议支持情况。 |
| 浏览器可用,部分应用不通 | 流量接管 | 应用是否遵循系统代理,是否需要 TUN。 |
| 连接命中了错误代理组 | 配置与规则 | 当前配置、规则顺序、代理组选择结果。 |
Clash for Windows 则是另一个独立图形客户端,常缩写为 CFW。它不是所有 Windows 端 Clash 客户端的统称,也不是 Clash Verge Rev 的旧名称。CFW 的旧教程可能包含 Profiles、Proxies、General 等页面名称;迁移时应按功能寻找对应入口,不要照搬其中的文件路径或服务安装步骤。
配置兼容:YAML 相似不等于直接通用
基础结构相似,是跨客户端迁移相对容易的原因。常见配置包含 proxies、proxy-groups、rules 等字段。但新协议、规则扩展、DNS 选项以及客户端自己的覆写机制,都可能带来差异。还要区分“包含完整配置的订阅”和“只返回节点列表的订阅”:后者通常需要客户端模板补齐代理组与规则。
先检查最小运行设置
下面是用于说明字段关系的片段,不包含节点和代理组,不应拿它覆盖现有完整配置。7890 是此例设置的混合代理端口,不代表每个客户端的默认值;实际端口应以当前客户端「设置」中显示的监听值为准。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
mixed-port:在同一个端口接受 HTTP 与 SOCKS 代理连接。allow-lan: false:不向局域网设备开放代理接入;仅本机使用时先保留这一限制。mode: rule:按照规则选择策略,不等于所有连接都经过远端代理。log-level: info:保留常规日志,便于查看配置加载与运行异常。
区分原始订阅与最终生效配置
客户端可能在启动内核前合并端口、DNS、TUN、规则补充和脚本处理结果。因此,订阅文件里写着一个值,实际运行时可能使用另一个值。排查时应检查客户端提供的运行配置或配置预览,再结合日志确认;不要只看下载到本地的原始 YAML。
控制接口也不是代理端口。external-controller 指定内核控制 API 的监听地址,客户端通过它读取状态和执行切换。若自行启用控制接口,优先绑定 127.0.0.1 并设置 secret,不要为了修复界面连接问题直接开放到所有网卡。订阅链接、控制密钥和节点凭据均不应出现在公开截图里。
Windows 选型:按流量接管需求检查
对普通 Windows 用户,优先选择仍在维护、内核来源明确、文档可查的图形客户端。不要只比较界面截图,也不要把“内置 mihomo”理解成所有网络问题都会自动解决。系统代理、TUN 和服务模式分别解决不同问题。
- 先用系统代理验证基本链路。导入配置,选择可用节点,打开系统代理,再访问目标网站。只有遵循系统代理设置的应用才会按这个入口连接。
- 再判断是否需要 TUN。部分游戏、命令行工具或自行管理代理的程序不会遵循系统代理。TUN 通过虚拟网络接口和路由接管流量,但实际覆盖范围还受路由排除、DNS 设置和应用行为影响。
- 按客户端要求安装服务模式。服务模式通常用于协助完成需要较高权限的操作,例如管理虚拟网卡或路由。它不提供节点,也不负责替代订阅。
- 保留日志入口。确认能查看内核启动错误、DNS 错误和规则命中结果。能定位故障,比单纯增加开关更重要。
在 Windows PowerShell 中,可用以下命令检查示例端口是否仍被进程占用。输出最后一列是进程 PID;看到监听记录只说明有程序占用端口,不代表该程序一定是当前打开的客户端。
netstat -ano | findstr ":7890"
如果客户端使用的不是 7890,把命令中的数字换成设置页显示的实际端口。随后打开「任务管理器」→「详细信息」,按 PID 查找进程。先正常退出对应程序,再重试启动新客户端,比直接反复更改端口更容易确认问题来源。
迁移清单:从旧客户端转到 mihomo 客户端
迁移目标不是完整复制旧软件的目录,而是恢复可用配置,并验证新客户端的接管行为。旧缓存、数据库和服务注册信息通常不适合直接搬进另一个客户端。
- 记录现状。保存订阅地址、手工添加的规则、代理组选择和本地端口。备份文件留在本机,分享前移除凭据。
- 停用旧接管。关闭旧客户端的开机启动、系统代理及 TUN,再退出程序。需要移除旧服务时,使用旧客户端对应的卸载入口。
- 重新导入订阅。在新客户端「配置」页导入,确认没有 YAML 解析错误或不支持的节点类型,再激活该配置。
- 分阶段测试。先验证系统代理,再验证规则模式,最后测试 TUN。一次只改变一项设置,方便从日志定位变化。
- 验证退出后的网络。退出新客户端,确认 Windows 代理设置恢复,并检查常用应用能否正常联网。异常时先排除遗留代理和路由。
最终记住三条对应关系:Clash 是历史起点,mihomo 延续并发展内核能力,Clash Verge Rev 提供管理这些能力的图形界面。选客户端时核对维护状态,读教程时核对界面名称,查兼容性时核对内核版本。这样才能把“软件叫什么”转化为“这台 Windows 设备需要怎么设置”。