2026-07-03 进阶内核 预计阅读 9 分钟

mihomo 内核与原版 Clash 差异对照:规则语法、DNS 与 TUN 新特性

对照 mihomo(Clash Meta)内核与原版内核的关键差异:新增协议支持、规则集与 GeoSite 用法、DNS 分流策略、TUN 模式实现,并说明旧配置迁移时的兼容要点。

背景:为什么会出现两套内核

Clash 项目最初的内核仓库由原作者维护,协议支持和规则语法相对保守,长期停留在一个稳定但功能有限的版本。社区在此基础上发起了 Clash Meta 分支,持续加入新协议、新规则类型和更完整的 DNS/TUN 实现,后来独立更名为 mihomo,成为事实上的社区主线。目前各家客户端(包括本站收录的多数 Windows、macOS、Android 版本)都已经把 mihomo 作为默认或可选内核,原版内核的更新频率明显放缓。

理解两者差异,对判断「为什么某条规则不生效」「为什么某个协议连不上」「配置文件搬到新客户端后报错」这类问题很有帮助——大多数根源都出在内核差异上,而不是配置文件本身写错了。

协议与特性支持差异

原版内核支持的协议集合基本固定在 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等早期主流协议。mihomo 在此基础上补齐了以下能力:

如果订阅节点里出现 vless、hysteria2、tuic 这类字段,而客户端提示节点类型不支持,通常就是仍在用原版内核,换成 mihomo 内核版本即可解决,不需要更换订阅或重新生成节点。

规则语法与 GeoSite/GeoIP 用法差异

原版内核的规则类型集中在 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR 和内置的 GEOIP,规则集需要以完整列表形式写进配置或单独维护规则文件,更新和维护成本较高。mihomo 引入了更细的规则类型和更高效的规则集机制:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example-ruleset/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

其中 rule-providers 支持定期从远程拉取并本地缓存,GEOSITE 规则直接引用预编译的域名分类库(如 category-ads-all、cn),不需要手工罗列域名。这类语法在原版内核里不被识别,若配置文件中出现 rule-providers 或 GEOSITE 却运行在原版内核上,会直接报语法错误或规则不生效,是排查规则失效问题时最先该确认的一点。

DNS 分流策略对比

原版内核的 DNS 模块功能简单,通常只能配置一组上游服务器,难以按目标域名做精细分流,容易出现「境内域名走境外 DNS 解析导致访问变慢」或「DNS 泄露真实归属地」的问题。mihomo 的 DNS 模块支持按策略分组:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver-policy:
    "geosite:cn": [223.5.5.5, 119.29.29.29]
    "geosite:geolocation-!cn": [https://1.1.1.1/dns-query]
  fake-ip-filter:
    - "*.lan"
    - "+.local"

nameserver-policy 可以按 GeoSite 分类分别指定解析服务器,境内域名走境内 DNS,境外域名走加密 DNS,从源头减少不必要的绕行。enhanced-mode 也从原版偏简单的实现,扩展出更稳定的 fake-ip 模式,配合 TUN 使用时兼容性更好。

如果从原版内核配置迁移到 mihomo,DNS 段的旧字段(例如部分早期版本使用的 dns.fallback 简单列表)建议按新语法重写,而不是直接照抄旧文件,否则可能只是不报错但实际未生效。

TUN 模式实现差异

TUN 模式让 Clash 以虚拟网卡形式接管系统全局流量,不依赖应用层的系统代理设置,对不支持代理协议的程序(游戏、部分命令行工具)尤为重要。原版内核的 TUN 实现出现较晚,配置项少,平台适配也有限,早期主要在 Linux 上可用,Windows/macOS 支持并不完整。

mihomo 的 TUN 模块重写了网络栈处理逻辑,常见配置如下:

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack 可选 system、gvisor 等不同网络栈实现,兼顾兼容性与性能;auto-route 和 auto-detect-interface 能自动配置路由表和识别出口网卡,减少手工设置路由的步骤。Windows、macOS、Android 客户端目前的 TUN(或称虚拟网卡/VPN 模式)入口基本都建立在 mihomo 内核之上,这也是选择内核版本时优先考虑 mihomo 的直接原因之一。

如何确认自己正在使用哪个内核

排查问题前,先确认手上跑的到底是哪套内核,能省下大量无用尝试。桌面客户端一般在「设置 — 关于」或「内核管理」页面直接显示内核名称与版本号,出现 mihomo 或 Meta 字样即为社区内核;若只显示 Clash v1.x 且没有额外标记,大概率是原版内核。命令行用户可以直接执行内核二进制加 -v 参数查看版本输出,mihomo 会打印自身名称与编译时间。另一种间接判断方式是在配置里临时加一条 GEOSITE 规则再重载:原版内核会因为不认识该规则类型而报错退出,mihomo 则正常加载。Android 端可以看 VPN/TUN 开关是否可用、节点列表是否能识别 VLESS 与 Hysteria2 节点,两项都支持的基本都是 mihomo 内核构建版本。

确认内核之后再对照下面这张思路表判断问题归属:节点类型报错、规则语法报错、DNS 分流失效、TUN 无法启用这四类现象,若发生在原版内核上,优先换内核而不是改配置;若已经在 mihomo 上仍然出现,才需要回到配置文件本身逐段核对字段拼写、缩进层级与策略组引用关系。

资源占用与稳定性的实际差别

功能更多通常意味着更高的开销,但 mihomo 的实际表现并不比原版内核差多少。日常几十个节点、两三个远程规则集的配置下,内存占用大致在几十兆到一百多兆之间,差异主要来自规则集缓存和 GeoSite/GeoIP 数据文件的加载,而不是内核本身的处理逻辑。真正影响占用的是三个可控项:规则集数量与更新频率、DNS 缓存条目上限、以及 TUN 网络栈的选择——gvisor 栈在用户态处理数据包,兼容性好但 CPU 占用略高;system 栈交由系统协议栈处理,吞吐更高,遇到个别环境不兼容时再回退到 gvisor 即可。

稳定性方面,mihomo 迭代频繁,新特性偶尔会带来回归问题,建议不要盲目追最新预览版;生产环境优先选带正式版本号的构建,遇到异常先回退到上一个可用版本,再到项目仓库确认是否为已知问题。原版内核虽然长期不更新,但也因此几乎不会出现新引入的缺陷,若你的配置只用到早期协议与基础规则,继续留在原版内核也没有明显风险。

旧配置迁移到 mihomo 的注意事项

把一份原版内核的配置文件迁移到 mihomo 内核,大多数情况下可以直接使用,因为 mihomo 对原版语法保持了向下兼容。但仍有几处需要留意:

  1. 检查是否使用了已弃用的字段名,例如个别版本更迭中重命名过的策略组参数,可对照最新示例配置逐一核对;
  2. 规则顺序敏感,原版配置里习惯把 MATCH 或 FINAL 放最后作为兜底,这条规则在 mihomo 中依然要保留在末尾,否则后续规则会被忽略;
  3. 策略组的 type 字段在 mihomo 中新增了 smart、load-balance 等选项,原版不识别的新类型如果误写进旧内核配置会导致启动失败;
  4. 如果配置中引用了远程规则集或 GeoSite/GeoIP 数据文件,首次在 mihomo 下运行时需要联网下载一次,离线环境要提前准备好本地文件。

总体来看,mihomo 已经是当前多数客户端的默认选择,新增协议、更精细的规则语法、按分类的 DNS 策略和更完整的 TUN 实现,都是原版内核短期内难以补齐的差距。除非有特殊的兼容性需求,日常使用建议直接选择集成 mihomo 内核的客户端版本,配置文件按新语法逐步调整即可,不必强行保留旧写法。

下载Clash