内核解析 预计阅读 12 分钟

mihomo 内核有哪些新特性:与原版 Clash 的功能差异清单

梳理 mihomo 新增的协议支持、规则集与 GEO 数据处理、TUN 增强等能力,对照原版 Clash 列出配置写法上的不同。

比较范围：原版 Clash、Premium 与 mihomo

mihomo 是 Clash Meta 项目更名后使用的内核名称。它延续了 Clash 的 YAML 配置体系，但在出站协议、规则表达、DNS 和流量接管方面持续扩展。客户端窗口里仍显示“Clash”或“Meta”，不代表当前运行的就是原版 Clash；界面名称、配置格式名称和内核名称需要分开看。

本文把“原版 Clash”限定为原项目停止维护前的开源内核，不把 Clash Premium 的能力混入其中。Premium 曾提供 TUN、规则提供者等扩展；因此，“原版开源内核没有某功能”不能推导为“历史上所有 Clash 分支都没有”。这一区分尤其影响旧配置迁移。

能力原版开源 Clashmihomo
HTTP、SOCKS、SS、VMess、Trojan 等常见出站支持，具体参数取决于版本延续支持，并扩展部分参数
VLESS、REALITY、Hysteria2、TUIC不能按 mihomo 写法直接使用支持，需匹配协议与服务端参数
规则提供者 rule-providers不是原版开源内核的通用能力支持多种行为与文件格式
GEOSITE 与逻辑规则不支持对应的 mihomo 扩展写法支持，需准备对应数据或规则
TUN 接管与 DNS 劫持不提供 mihomo 的这套配置支持，受系统权限和路由环境影响
Fake-IP DNS已有相关能力延续并扩展，不是首次引入

协议扩展：先看订阅里的 type，再看传输参数

最容易感知的差异是新增出站协议。旧内核遇到 type: hysteria2 或 type: vless 时，可能在加载阶段就报告不支持的代理类型。更换策略组、调整规则顺序都解决不了这类问题，因为出站尚未成功建立。

VLESS 与 REALITY 不是两个可互换的节点类型

VLESS 是代理协议；REALITY 是可用于相应出站配置的安全握手机制。在 mihomo 中，VLESS 节点通常以 type: vless 声明，REALITY 相关内容位于 reality-opts。把节点类型直接写成 reality，不是等价转换。

  • uuid 是认证参数，必须与服务端一致。
  • servername、reality-opts.public-key 和 short-id 必须按服务端提供的信息填写，不能从域名自行猜测。
  • flow、传输方式与指纹选项也有组合约束；不能只增加一个字段，就把已有 VMess 节点变成 VLESS 节点。

Hysteria2 与 TUIC 需要可用的 UDP 路径

Hysteria2、TUIC 基于 QUIC，连接能否建立不只取决于内核是否支持。如果当前网络封锁或严重限制 UDP，TCP 节点能用而这两类节点超时并不矛盾。Hysteria 与 Hysteria2 也不是仅改名称的同一种配置，应使用订阅实际声明的协议类型。

例如服务端监听 UDP 443 时，需要检查本机防火墙、上游网络及服务端安全组是否放行该端口。浏览器能通过 TCP 443 打开网页，并不能证明同一地址上的 UDP 通道可用。也不要把协议切换描述为固定提速：链路丢包、服务端容量和限速策略都会改变结果。

规则集扩展：从内嵌 rules 到独立维护的数据文件

原版 Clash 已有按顺序匹配的规则机制，mihomo 没有改变“第一条命中规则决定出站”的基本逻辑。扩展主要体现在规则来源与表达能力：可以通过 rule-providers 管理外部规则集，再用 RULE-SET 引用；还可使用 AND、OR、NOT 等逻辑规则组合条件。

本地规则提供者的最小结构

下面两段分别保存为主配置与规则文件。示例只用 DIRECT，用于验证规则加载结构，不会自动创建代理节点。先在工作目录下建立 rules 文件夹，再放入文件；相对路径按内核运行环境解析，不一定是桌面上所见的订阅文件位置。

# 主配置中的相关片段
rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - RULE-SET,work-domains,DIRECT
  - MATCH,DIRECT
# ./rules/work-domains.yaml
payload:
  - '+.example.com'
  - 'example.org'

behavior: domain 表示文件内容是域名匹配模式，不应在其中直接混入 IP-CIDR,192.168.0.0/16。如果希望一份规则集包含完整的多种规则语句，应选择 classical 并按其格式组织内容。

  • domain：适合域名集合。
  • ipcidr：适合 IP 网段集合。
  • classical：适合包含多种规则类型的规则集。
  • mrs：是 mihomo 支持的二进制规则格式，主要用于 domain、ipcidr 行为，不等于任意 YAML 文件换个扩展名。

规则提供者与节点提供者也不能混用。rule-providers 提供匹配条件，proxy-providers 提供代理节点。订阅更新成功，只说明对应资源完成更新，不代表另一类资源已经下载或生效。

GEO 数据：GEOIP 查地址，GEOSITE 查域名分类

GEOIP 规则并非 mihomo 独有；原版 Clash 已能进行基于地域数据的 IP 匹配。mihomo 的变化之一是增加 GEOSITE 等数据驱动能力，并提供不同 GEO 数据加载与更新选项。二者的匹配对象不同，不能把一个关键字替换成另一个就期待结果一致。

规则示例匹配依据使用前检查
GEOIP,CN,DIRECT目标 IP 所属的数据库条目数据文件可读；域名连接可能需要解析
GEOSITE,cn,DIRECT域名是否属于指定分类已加载 GEOSITE 数据，且包含 cn 分类
GEOIP,CN,DIRECT,no-resolve已有目标 IP 的地域信息不会为了这一条规则额外解析域名

geodata-mode: true 用于切换 GEOIP 的数据工作方式，通常涉及 GeoIP.dat；默认的另一种方式使用 MMDB 数据。GEOSITE 使用自己的域名分类数据，并不是把 GEOIP 模式打开后就能推导出全部域名分类。资源文件、内核版本与分类名称需要一起核对。

不要把 cn 理解成实时网络测量结果。数据集由维护者整理，某个域名是否归入某类、某段 IP 归属何处，都可能随版本变化。出现误分流时，应先确认具体命中的规则和本地数据更新时间，再决定增加一条更靠前的精确域名规则。

TUN 增强：接管范围不等于全部流量走代理

系统代理通常只影响遵循系统代理设置的应用；TUN 通过虚拟网络接口和路由接管更多 IP 流量。mihomo 中的 TUN 能力适合处理不读取系统代理的程序，但它仍然受路由、权限和规则影响。开启 TUN 后，命中 DIRECT 的连接仍会直连。

# 合并到已有且能够正常联网的 mihomo 配置中
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1

这段配置只展示接管与 DNS 的关联，不包含代理节点。1053 是内置 DNS 监听端口；dns-hijack 中的 53 是待拦截的传统 DNS 目标端口，两者不是必须写成同一个数字。示例的上游 DNS 只是演示值，实际环境中应换成可达且符合网络策略的解析服务。

stack 与权限分别排查

  • system、gvisor、mixed 对应不同协议栈处理方式；mixed 通常以系统栈处理 TCP、以 gVisor 处理 UDP。可用性仍需结合当前平台与版本确认。
  • Windows 通常需要管理员权限或客户端安装的特权服务；Linux 通常需要相应网络管理权限，并检查 /dev/net/tun；macOS 需按客户端要求授权。
  • auto-route 会修改路由安排。与其他 VPN、虚拟机网络或企业接入工具并用时，应先关闭另一套接管工具进行对照测试。
  • 应用自带的 DoH 使用 HTTPS，不会因为拦截传统的 53 端口 DNS 就自动进入同一条解析链路。

DNS 与嗅探：补充域名信息，不代替代理规则

Fake-IP 的基本思路是先给域名分配映射地址，再在连接进入内核时恢复域名信息。示例中的 198.18.0.1/16 位于常用于该用途的基准测试保留地址范围。看到这一类解析结果，不应直接判断为公网 DNS 故障；应检查发起连接的应用是否也由同一个内核接管。

mihomo 的嗅探功能可尝试从 HTTP Host、TLS SNI 等协议内容获得域名，帮助只有目标 IP 的连接参与域名规则匹配。它不是解密 HTTPS，也不保证每条连接都能提取域名。遇到加密握手信息、非标准协议或应用特定连接方式时，仍可能无法得到可用名称。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]

上例限定了嗅探协议和目标端口。若业务依赖指定 IP、使用内部证书域名，或在启用后出现连接行为变化，应先对照关闭嗅探的结果，再按当前版本支持的跳过条件缩小范围。不要把嗅探当成修复所有规则未命中的统一开关。

迁移顺序：语法检查、节点测试、规则验证、最后开启 TUN

旧配置不需要为迁移而全部重写。先保留混合端口、已有节点与简单规则，再逐项加入新特性，更容易区分问题来自节点参数、规则数据还是系统接管。以下顺序适用于独立内核，也能作为图形客户端的检查清单。

  1. 保存可恢复副本。记录原客户端、内核版本、配置来源和工作目录。若客户端有订阅覆写或合并配置功能，也要保留这些内容。
  2. 检查配置能否加载。使用下面的测试命令。它能发现 YAML、部分字段和资源加载问题，但不能证明远端节点一定可连。
  3. 先测试代理入口。确认 mixed-port 实际监听的端口，再通过本地代理发送请求。下例使用 7890；若配置不同，需要同步修改命令。
  4. 核对规则命中。查看连接记录中的目标域名、命中规则和最终出站。增加 GEOSITE 或 RULE-SET 后，再次测试同一目标。
  5. 最后测试 TUN。先验证系统代理路径可用，再开启 TUN。分别测试浏览器、未读取系统代理的应用、局域网访问和 DNS 解析。
mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com/

如果主配置引用相对路径，测试时的 -d 应与预期工作目录一致，并提前准备规则文件。测试命令通过后，还要检查客户端最终交给内核的配置；有些客户端会把订阅、覆写和界面设置合并后再运行，磁盘上的订阅原文不一定等于生效配置。

三类报错对应三条排查路径

  • 不支持的代理类型：先确认内核名称与版本，再确认订阅是否输出 mihomo 兼容格式；不要先改 DNS。
  • 规则集或 GEO 数据加载失败：检查路径、文件格式、访问权限及下载可达性；不要直接删除全部分流规则掩盖问题。
  • 代理可用，TUN 不可用：检查权限、默认网卡、冲突路由和 DNS 接管；不要据此认定远端节点失效。

客户端入口与安装说明见下载中心；首次导入订阅可参考使用指南。需要进一步核对 DNS、策略组与 TUN 字段时，可在配置大全中按字段查阅。

下载客户端