Clash 原版、Meta 与 mihomo 内核区别对比：协议支持与选择建议
三种内核名称相近但能力差距明显。本文从协议支持、规则语法、TUN 实现与维护状态四个维度逐项对比，并给出不同客户端与使用场景下的内核选择结论。
下载客户端时经常会在设置里看到"内核版本"或"内核类型"这一项，选项通常是 Clash Premium、Clash Meta、mihomo 三者之一，偶尔还能见到停止更新的原版 Clash。这几个名字看起来只是版本号的差异，实际背后是完全不同的代码分支，功能集合、协议支持范围、更新频率都不一样。选错内核最直接的后果是某条规则语法解析失败、某个协议节点连不上，或者 TUN 模式启动后系统流量没有被正确接管。这篇文章把四条主线捋清楚，帮助判断当前客户端用的是哪一种内核，以及要不要手动切换。
内核谱系：一个项目分出的三条分支
要理解差异，先要理清历史脉络。最早的 Clash 由 Dreamacro 用 Go 语言编写，长期是事实标准，规则引擎简洁、资源占用低，但作者在 2023 年停止了公开维护，仓库归档后不再合并新协议的支持。这就是通常说的"原版 Clash"或 Clash Premium（早期曾有付费内核 Premium 分支，提供规则测速等增强功能，但底层协议集合与开源版基本一致）。
原版停更后，社区在其基础上发起了 Clash.Meta 分支，加入了原版一直缺席的协议与功能，例如 TUN 模式的完整实现、Hysteria、TUIC、WireGuard 出站等。这个分支后来正式改名为 mihomo，目前是社区维护最活跃、更新最频繁的内核，多数主流客户端（Clash Verge Rev、FlClash、Clash Meta for Android 等）默认内置的都是 mihomo，只是客户端界面上仍习惯称呼为"Meta 内核"，容易让人以为 Meta 和 mihomo 是两个不同的东西——实际上 mihomo 就是 Clash.Meta 改名后的延续版本，二者是同一条分支的不同阶段。
提示：如果客户端设置页写的是"Meta 内核"而版本号形如 v1.18.x 或更高，基本可以确认实际运行的就是 mihomo，只是命名沿用了旧称。
协议支持对比：差距集中在新协议
三者在 Shadowsocks、VMess、Trojan 这几个"老三样"协议上没有实质差异，都能正常解析和连接。差距主要体现在近几年新出现的协议和传输方式上：
| 协议/特性 | 原版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| Shadowsocks / VMess / Trojan | 支持 | 支持 | 支持 |
| Hysteria / Hysteria2 | 不支持 | 支持 | 支持 |
| TUIC | 不支持 | 支持 | 支持（含 v5） |
| WireGuard 出站 | 不支持 | 部分支持 | 支持 |
| VLESS + XTLS/Vision | 不支持 | 部分版本支持 | 支持 |
| ShadowTLS | 不支持 | 支持 | 支持 |
| TUN 完整接管 | 受限 | 支持 | 支持并持续优化 |
可以看出，凡是 2021 年之后出现的协议，原版 Clash 基本一律不支持，这也是它逐渐被淘汰的直接原因。Clash Meta 作为过渡阶段的分支覆盖了大部分新协议，但部分实现停留在早期版本，遇到协议规范更新（比如 TUIC 从 v4 升级到 v5）时可能滞后。mihomo 作为当前活跃分支，新协议的跟进速度最快，通常协议标准发布后一到两个小版本内就会合并支持。
订阅节点解析失败的常见原因
如果订阅里出现 Hysteria2 或 TUIC 节点，导入后显示"未知协议"或直接被过滤掉，多半是客户端内置的还是原版 Clash 内核。此时不需要重新下载客户端，检查一下设置里是否有"内核切换"选项，切到 Meta 或 mihomo 内核后重新导入订阅通常就能解决。
规则语法差异：Meta 系新增的匹配类型
规则集（Rule Provider）与规则语法上，mihomo/Meta 相对原版新增了几类原版不认识的匹配规则，直接写进原版内核的配置文件会导致启动失败或规则被静默忽略：
- RULE-SET：引用外部规则集文件，原版早期版本不支持增量更新的规则集格式。
- GEOSITE / GEOIP（配合 mmdb/dat 数据库）：按域名或 IP 归属地打包分类，原版对新格式数据库的兼容性较差。
- SCRIPT：允许用简单脚本逻辑做分流判断，仅 Meta/mihomo 支持。
- SUB-RULE：子规则集嵌套引用，mihomo 后期版本才加入，用于精简大型规则文件。
- process-name / process-path 进程级匹配：按发起请求的应用进程分流，依赖 TUN 模式获取进程信息，原版不具备这类能力。
rules:
- RULE-SET,private,DIRECT
- RULE-SET,reject,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY上面这段常见的规则片段里，RULE-SET 和 GEOSITE 都要求内核具备对应解析能力。如果把这类配置文件塞进只支持原版语法的客户端，日志里通常会报"unsupported rule type"或者规则整体不生效，退回到默认策略组，表现就是明明配置了分流规则，但所有流量还是走了同一条路径。
TUN 模式实现：接管完整度决定使用体验
TUN 模式指的是内核在系统层建立一个虚拟网卡，把设备上所有应用的流量都强制导入代理处理流程，不再依赖单个应用主动设置代理地址。这也是三种内核差距最直观的地方：
- 原版 Clash：TUN 支持在项目后期才补上，实现比较基础，对 IPv6、DNS 劫持的处理不完整，实际使用中经常出现部分应用绕过代理的情况。
- Clash Meta：重写了 TUN 实现，支持自动路由表配置、DNS 劫持、进程级过滤，覆盖了 UWP 应用、系统服务等原版处理不了的流量类型。
- mihomo：在 Meta 的基础上持续打磨，对 Android 平台的 VpnService 集成、iOS 平台的 NetworkExtension 适配都做了针对性优化，同时修复了大量因系统版本升级引发的 TUN 兼容性问题。
对安卓用户来说，这一点尤其关键：Clash for Android 系客户端能不能稳定接管全局流量、能不能正确处理 DNS 请求走向，核心取决于内置的是不是 mihomo 内核。如果发现某些应用（尤其是有网络隔离机制的系统级应用）始终绕过代理，先确认客户端内核版本，再排查具体应用的网络设置。
维护状态与更新频率：决定长期可用性
协议和语法层面的静态对比只能反映当下的状态，实际选择时更该关注的是维护活跃度——代理协议本身在持续演进，内核如果停止更新，用不了多久就会跟不上服务器端的协议版本。
| 维度 | 原版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| 仓库状态 | 已归档，不再更新 | 已并入 mihomo，独立分支停止推进 | 活跃维护 |
| 版本发布节奏 | 无 | 历史遗留 | 数周一个小版本 |
| 安全修复 | 不再提供 | 不再提供 | 持续跟进 |
| 新协议合并速度 | 不适用 | 不适用 | 较快 |
简单说，Clash Meta 这个名字目前更多是历史遗留的称呼，实际代码演进已经全部转移到 mihomo 仓库，继续维护"Clash Meta"这个分支名称的客户端，本质上用的也是 mihomo 编译产物，只是命名没有及时更新。真正意义上还在使用原版 Clash 内核、且从未升级过的客户端已经比较少见，一旦遇到，规则语法和协议支持都会明显落后。
不同场景下的内核选择建议
结合上面四个维度，给出几种典型场景的判断依据：
- 日常使用、订阅节点较新：优先选择内置 mihomo 内核的客户端，新协议兼容性和 TUN 稳定性都更有保障，遇到问题社区也能更快得到修复。
- 依赖复杂分流规则、大型规则集：确认客户端支持 RULE-SET 与 SUB-RULE 语法，这类场景基本排除原版内核。
- 纯静态配置、长期不换节点：如果订阅只用 Shadowsocks/VMess 这类基础协议，且不需要 TUN 全局接管，即使客户端仍标注为"Meta 内核"也通常够用，不必频繁折腾切换。
- 安卓设备上需要全局代理与分应用规则：务必确认客户端 TUN 实现基于 mihomo，否则进程级分流和部分系统应用的流量接管会不完整。
判断当前客户端具体使用哪种内核，最直接的方式是查看设置页的"关于"或"内核信息"栏目，通常会显示类似 mihomo v1.18.x 这样的版本字符串；如果只写着一个不带来源说明的版本号，也可以在配置文件里加入一条新语法规则（例如 RULE-SET）测试是否报错，作为间接验证手段。
注意：切换内核后原有配置文件建议重新校验一遍，部分策略组写法（如出站分组的 type 字段取值）在不同内核间存在细微差异，直接复用旧配置有小概率触发解析报错。
排查内核问题的简明步骤
遇到"规则不生效""协议连不上""TUN 开启后部分应用无法访问网络"这类问题时，可以按下面顺序排查，通常几分钟就能定位是不是内核不匹配导致的：
- 查看客户端日志，搜索是否出现 unsupported、unknown rule type、protocol not supported 一类关键字。
- 在设置里确认当前内核版本号与来源，判断是不是原版 Clash 或过旧的 Meta 分支。
- 若客户端提供内核切换选项，切换到 mihomo 分支后重新加载配置文件。
- 规则和协议仍有问题，检查配置文件里对应字段的写法是否和当前内核版本的文档一致，尤其注意规则集格式（YAML/文本）与字段命名的变化。
总体而言，三种内核并非平级的可选项，而是一条技术演进链条：原版 Clash 是起点但已经停止前进，Clash Meta 是中间过渡阶段，mihomo 是当前的延续与终点。除非有明确的兼容性理由（例如某些老旧配置文件严格依赖原版行为），日常使用没有必要坚持旧内核，选择内置 mihomo 的客户端能省去大部分因协议或语法不兼容引发的排查工作。