内核发展脉络:为什么会出现 mihomo
原版 Clash 内核由 Dreamacro 主导开发,长期是 Clash 生态事实上的标准实现,协议支持覆盖 Shadowsocks、Vmess、Trojan 等主流方案,规则引擎与配置格式也成为后续众多客户端的基准。2023 年前后,原作者账号与相关代码仓库被下架,原版内核的更新随之停止。
社区随即以 Clash Meta 分支延续开发,后重命名为 mihomo。这不是简单的改名,而是在原有代码基础上持续合入新协议、新特性,逐渐形成一套功能范围明显超出原版的实现。目前主流的 Clash 类客户端,包括 Clash Verge、Clash for Windows 的后续替代品、多数移动端客户端,底层内核基本都已切换为 mihomo,原版内核仅作为历史版本存在于部分老旧客户端中。
理解这段脉络有一个直接的现实意义:如果你正在使用某个仍标注"Clash 内核"却长期不更新的客户端,大概率用的是原版内核,协议支持范围会明显落后于当前主流节点服务商提供的协议种类。
协议支持范围对比
协议支持是两者最直观的差异。原版内核支持的协议种类基本停留在停止维护前的状态,mihomo 在此基础上持续新增,目前的支持范围明显更广。
| 协议 | 原版 Clash 内核 | mihomo |
|---|---|---|
| Shadowsocks | 支持 | 支持,含更多加密方式 |
| Vmess | 支持 | 支持 |
| Trojan | 支持 | 支持 |
| VLESS | 不支持 | 支持 |
| Hysteria / Hysteria2 | 不支持 | 支持 |
| TUIC | 不支持 | 支持 |
| WireGuard(作为出站) | 不支持 | 支持 |
| SSH(作为出站) | 不支持 | 支持 |
其中 VLESS 与 Hysteria2 是近两年节点服务商侧使用率上升较快的两类协议。VLESS 常搭配 XTLS 或 Reality 传输层用于对抗特征识别;Hysteria2 基于 QUIC,在弱网、高延迟或存在丢包的链路上表现出比传统 TCP 类协议更好的吞吐稳定性。如果订阅里包含这两类协议节点,原版内核会直接解析失败或节点不可用,必须切换到 mihomo 内核的客户端才能正常连接。
判断自己使用的客户端是哪个内核,可以查看客户端的"内核版本"或"关于"页面。标注 mihomo 或 Clash.Meta 的即为新内核;仅标注纯数字版本号且长期停留在旧版本的,多半是原版内核。
TUN 模式:从外部插件到内置能力
TUN 模式(也称虚拟网卡模式)是指内核在系统层创建一个虚拟网络接口,拦截全部或指定范围的系统流量并交由代理规则处理,不再依赖应用层的系统代理设置。这种方式的优势在于覆盖面更广:不支持系统代理配置的程序、部分游戏客户端、系统级服务的网络请求,都能被纳入分流范围。
原版 Clash 内核本身不包含 TUN 能力,早期实现依赖额外的辅助程序或系统层驱动配合才能实现类似效果,配置门槛较高,且跨平台一致性差,Windows、macOS、Linux 各自需要不同的适配方案。
mihomo 将 TUN 模式作为内核原生功能内置,配置项直接写在核心配置文件的 tun字段下,不再需要额外驱动或插件配合(部分平台仍需要系统授予虚拟网卡创建权限,这属于系统层的正常授权流程)。一个典型的 mihomo TUN 配置片段:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack字段可选 system、gvisor等不同网络栈实现,分别在兼容性与性能上有所取舍;auto-route开启后由内核自动接管系统路由表,避免手动配置路由规则。这部分能力是原版内核完全不具备的,也是许多用户从原版切换到 mihomo 的直接原因之一。
规则引擎与规则集能力增强
规则分流是 Clash 类客户端的核心机制,通过匹配域名、IP 段、进程名等条件,决定每一条连接走哪个代理节点或是否直连。原版内核的规则类型集中在 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP等基础类型上,规则集(Rule Provider)机制也相对简单。
mihomo 在此基础上做了几方面增强:
- 规则集格式扩展:除原有的 YAML 列表格式外,新增对 MRS(mihomo 专属二进制规则集格式)的支持,体积更小、加载更快,适合体量较大的规则库。
- 逻辑规则:支持
AND、OR、NOT等逻辑组合规则,可以将多个匹配条件组合成一条规则,减少规则数量、提升可维护性。 - 进程匹配规则:
PROCESS-NAME、PROCESS-PATH等按发起连接的进程名称或路径分流的规则类型,在原版中支持范围有限,mihomo 下更完整,尤其在桌面端按应用分流的场景中很实用。 - 子网规则与脚本规则:进一步细化了匹配维度,便于处理复杂的分流策略。
对于已经在用规则集(而非把全部规则写在主配置文件里)的用户,这部分变化通常是无感的——规则集地址本身不受内核切换影响,但如果规则集作者开始使用 mihomo 专属的规则类型或 MRS 格式,原版内核解析该规则集时就会出错或规则失效。
配置文件兼容性与迁移要点
mihomo 在设计上保持了对原版 Clash 配置格式较高的向后兼容,基础字段结构(proxies、proxy-groups、rules等顶层字段)基本一致,这意味着大多数原版配置文件可以直接在 mihomo 客户端下正常加载运行。但从原版切换到 mihomo 时,仍有几个需要留意的点:
- 新协议节点需要客户端支持才能生效:配置文件里出现 VLESS、Hysteria2 等原版不支持的协议节点时,原版内核会跳过该节点或直接报错,切换到 mihomo 后节点才会正常出现在代理组列表中。
- 字段名存在部分差异:少数字段在 mihomo 中有更精确的命名或新增了可选参数,例如 TUN 相关配置整体是 mihomo 新增字段,原版配置文件中不存在,需要根据 mihomo 文档补充,而不是从旧配置里"复制"过来。
- Provider 拉取行为略有不同:mihomo 对 Proxy Provider、Rule Provider 的健康检查与更新策略做了优化,拉取失败时的重试逻辑更稳健,但基础字段(
url、interval、path)保持一致,无需改动。 - GEOIP 数据库格式:mihomo 默认使用 mihomo geoip 数据库,与原版使用的 GeoLite2 系列数据库格式不完全相同,首次切换时客户端通常会自动下载适配的数据库文件,若网络环境导致下载失败,GEOIP 类规则会暂时不生效,直连与代理判断退化为按其他规则处理。
迁移前建议先备份原有配置文件。切换内核后如果发现代理组为空或规则大量失效,优先检查配置文件里是否引用了 mihomo 才支持的字段或规则集格式,而不是怀疑订阅本身失效。
对绝大多数普通用户而言,迁移路径其实很简单:直接更换支持 mihomo 内核的客户端安装包,配置文件或订阅链接原样导入即可,无需手动改写字段。只有在自行编写复杂规则或使用了逻辑规则等 mihomo 专属语法时,才需要额外关注格式细节。
该如何选择:是否需要切换到 mihomo 内核
结合前面的对比,给出几条判断依据:
- 如果订阅节点包含 VLESS、Hysteria2、TUIC 等新协议,必须使用 mihomo 内核,原版内核无法解析这些节点。
- 如果需要 TUN 模式实现全局透明代理,尤其是需要覆盖游戏、系统级服务等不支持系统代理的场景,mihomo 内核是唯一原生支持的选择。
- 如果只使用 Shadowsocks、Vmess、Trojan 等基础协议,且不需要 TUN 模式,原版配置在两种内核下都能正常工作,但由于原版内核已停止更新,长期使用仍建议切换到持续维护的 mihomo,以获得安全更新与稳定性改进。
- 规则集作者若已迁移到 mihomo 专属语法或 MRS 格式,继续使用原版内核会导致规则集加载失败,这种情况下切换内核是唯一解决方式。
目前主流 Clash 类客户端已普遍默认集成 mihomo 内核,并在客户端设置中提供内核版本管理入口,允许在多个 mihomo 版本之间切换,而不必额外单独下载内核文件。对于新用户,直接选择当前维护中的客户端安装,基本不会遇到内核选择的问题;对于长期使用原版内核老客户端的用户,建议评估节点协议与功能需求后,尽快迁移到基于 mihomo 的替代客户端。