进阶配置 预计阅读 12 分钟

mihomo 与原版 Clash 内核区别：新增协议、规则集语法与 TUN 实现对比

梳理 mihomo（原 Clash Meta）相对原版内核的主要变化：VLESS、Hysteria2 等协议支持，rule-providers 写法，以及 TUN 栈与 DNS 行为差异。

先区分内核、客户端与 Clash Premium

比较内核前，需要把三个层次拆开。内核负责解析配置、建立代理连接、处理 DNS 与匹配规则；桌面或移动客户端负责配置管理、托盘菜单、订阅更新和权限申请；订阅则提供节点、策略组与规则数据。客户端名字里有 Clash，并不代表它运行原版 Clash，也不代表它支持所有 mihomo 配置。

原版 Clash 开源内核与 Clash Premium 也不是同一套功能集合。Premium 是原项目提供的闭源增强内核，历史上包含 TUN、规则集等增强功能。mihomo 是从 Clash Meta 延续而来的开源内核，保留大量 Clash 风格的 YAML 配置结构，同时继续扩展协议、路由与 DNS 功能。原项目已停止维护，迁移时应按实际二进制版本核对，而不是把旧客户端名称当成功能清单。

对象主要职责核对位置
原版 Clash 开源内核传统代理协议、策略组与规则分流内核版本与配置解析日志
Clash Premium原版基础能力及历史增强功能Premium 构建日期与对应文档
mihomo新增协议、规则集扩展、TUN 与 DNS 配置实际运行的 mihomo 版本
图形客户端导入订阅、启动内核、管理权限与配置覆写客户端设置、启动日志与运行配置

用命令确认实际版本

mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml

第一条查看当前二进制的版本信息；第二条指定工作目录与配置文件，执行配置测试。这里的文件应当已经存在，测试通过也只说明配置能够解析，不等于节点可用。图形客户端可能使用内置内核，终端里的 mihomo 与客户端启动的文件不一定相同，应同时检查客户端日志。

新增协议：VLESS、REALITY 与 Hysteria2

mihomo 与旧内核最直接的差异，是能否识别订阅中的节点类型及其参数。原版 Clash 的常见协议包括 Shadowsocks、VMess、Trojan、SOCKS 和 HTTP。mihomo 扩展了 VLESS、Hysteria2、TUIC 等协议支持，也支持特定协议组合中的 REALITY。不能仅把 YAML 的 type 改掉，就把旧节点转换为另一种协议；服务端必须提供对应入口。

功能mihomo 配置要点常见误区
VLESS核对 UUID、传输方式、TLS 与 flow将 VMess 节点的类型直接改成 VLESS
REALITY核对服务端要求的 SNI、公钥与 short-id把 REALITY 当作独立的节点类型
Hysteria2使用 type: hysteria2，核对密码与 TLS 参数复用 Hysteria 第一代的整段配置
TUIC核对服务端版本、认证字段与 UDP 连通性只测试 TCP 端口便判断节点正常

协议支持与网络条件分别判断

Hysteria2 与 TUIC 基于 QUIC，连接依赖 UDP。局域网、防火墙或运营商线路限制 UDP 时，即使配置测试通过，也可能出现握手超时。VLESS 的可用性则要结合实际传输方式判断，不能把所有 VLESS 节点归为同一种网络行为。协议名称本身也不能保证更低延迟或更高吞吐。

  • 提示不支持节点类型：先确认客户端是否真正启动了 mihomo，以及订阅是否面向该内核输出。
  • 提示认证失败：核对 UUID、密码、服务端协议版本，避免先修改 DNS。
  • 提示 TLS 握手错误：核对系统时间、SNI 与证书要求，不把跳过证书验证当作常规修复。
  • QUIC 节点持续超时：换网络对照测试，再检查 UDP 出站与服务器状态。

rule-providers：沿用结构，核对 behavior 与 format

rule-providers 并非 mihomo 独有，Clash Premium 已支持这一机制。迁移时通常可以沿用“声明规则集，再用 RULE-SET 引用”的基本结构。规则集负责描述匹配对象，rules 中的引用负责指定命中后的策略；两者不要混写。

本地 domain 规则集示例

下面片段合并到现有配置使用。它把示例域名规则送往 DIRECT，不依赖节点名称。工作目录内需要有 rules/local-domains.yaml 文件；如果已有 rule-providers 或 rules，应合并内容，不能重复创建同名顶层键。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

rules/local-domains.yaml 的文件内容：

payload:
  - '+.example.com'
  - 'intranet.example.net'

+.example.com 用于匹配该域名及其子域名。这个示例选择直连兜底，只演示引用关系，不是可直接替代现有订阅的代理方案。实际迁移时，应保留自己的代理策略组与末尾兜底规则。

三种 behavior 不可互换

  • domain：条目是域名或支持的域名匹配表达式，不带 DOMAIN-SUFFIX 前缀。
  • ipcidr：条目是地址网段，例如 192.168.0.0/16，不是完整规则语句。
  • classical：条目是规则表达式，例如 DOMAIN-SUFFIX,example.com，通常不在条目末尾写策略名称。

如果把 DOMAIN-SUFFIX,example.com 放进 behavior: domain 的文件，即使 YAML 缩进正确，也属于内容格式不匹配。检查规则集时，应同时查看提供器声明和下载后的文件，而不是只看文件扩展名。

mihomo 的规则集格式扩展

mihomo 支持 YAML、纯文本及 MRS 等规则集格式。MRS 是面向规则集的二进制格式，适用于 domain 与 ipcidr，不用于 classical。旧 Premium 配置不能据此推断可以直接读取 MRS。引入这些格式前，应确认所用 mihomo 版本和规则源说明，避免把较新的配置字段复制进旧内核。

规则仍然从上到下匹配。把 MATCH 放到规则集引用前面，后续规则就没有正常参与匹配的机会。排查分流错误时，优先看连接详情中的命中规则与实际策略，而不是只看策略组当前选中的节点。

TUN 实现：栈选择、路由接管与系统权限

系统代理与 TUN 不是同一入口。系统代理让遵循系统设置的应用向代理端口发起连接；TUN 创建虚拟网络接口，结合路由规则接收 IP 流量。TUN 更适合处理不遵循系统代理的应用，但是否接管某条连接，仍受路由、接口选择、排除项及操作系统权限影响。

原版开源 Clash 与 Premium 的 TUN 功能范围不同，不能概括成“所有 Clash 都有 TUN”。Premium 历史 TUN 方案与 gVisor 栈相关；mihomo 提供 system、gvisor、mixed 等栈选择。具体支持范围应以平台与版本为准，不能直接套用另一内核的 TUN 段。

stack 值处理方式选择建议
system使用系统网络栈相关实现按客户端默认值先建立可用基线
gvisor使用用户态网络栈处理流量用于兼容性对照，不预设一定更快
mixed结合 system 的 TCP 与 gVisor 的 UDP 处理核对当前平台支持后再测试

桌面环境的配置片段

mixed-port: 7890
allow-lan: false
mode: rule

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

这里的 7890 是示例混合代理端口，不是所有客户端的固定值。auto-route 用于自动配置路由，auto-detect-interface 帮助选择出站接口；它们不能代替权限申请。Windows 上通常需要客户端服务或提权机制，Linux 上需要适当的网络管理权限，macOS 上则要按客户端实现完成授权。

  1. 关闭其他 VPN 或另一个代理客户端的 TUN，先减少路由竞争。
  2. 确认系统代理模式可用，再单独启用 TUN，避免同时引入两组问题。
  3. 检查日志是否出现虚拟接口创建失败、路由添加失败或权限不足。
  4. 切换 Wi-Fi、有线网络或休眠恢复后，重新检查出站接口与路由。

DNS 与 Fake-IP：保留机制，重新核对解析路径

Fake-IP 并不是 mihomo 新增的概念。它通过映射地址建立域名与连接之间的关联，帮助内核按域名匹配规则。迁移时真正需要关注的是：DNS 请求有没有进入内核、哪些域名需要返回真实地址，以及代理服务器域名使用哪条解析路径。

将 DNS 与 TUN 分开验证

dns:
  enable: true
  listen: 127.0.0.1:7874
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

这是解析行为的演示片段：DNS 监听在本机 7874，Fake-IP 使用 198.18.0.1/16 范围，上游是两个明确的 IPv4 DNS 地址。上游应按实际网络和隐私要求选择，此处并不保证它们适合所有线路。fake-ip-filter 只是排除 Fake-IP 分配，不等于强制直连规则，也不能替代本地 DNS 服务器的配置。

在安装了 dig 的环境中，可以直接查询内核 DNS：

dig @127.0.0.1 -p 7874 example.com A

未命中过滤项时，响应通常会出现配置范围内的映射地址。这是预期机制，不是域名服务器返回了错误公网地址。随后访问该域名，再检查内核连接记录，确认连接能关联到域名并命中预期规则。

加密 DNS 与节点域名解析

  • 浏览器独立 DoH：浏览器可能绕过系统 DNS 路径。排查时先统一解析入口，再比较行为。
  • TUN 的 DNS 劫持：any:53 面向传统 DNS 流量，不能将它理解为能自动接管所有 DoH、DoT 请求。
  • 节点域名解析：mihomo 可用 proxy-server-nameserver 指定代理服务器域名的解析器，减少启动时解析路径相互依赖的问题。
  • 规则参与 DNS 出站：respect-rules 等设置会改变 DNS 连接的路由行为。需要按当前版本说明配套配置，不能只打开一个开关。

局域网服务访问异常时，应核对本地域名后缀、路由器 DNS 和网段规则。仅添加 *.lan 不会覆盖企业内部使用的所有域名。切换增强模式后还要考虑浏览器、系统与应用缓存；旧缓存中的映射地址可能短时间保留。

从 Clash Premium 迁移到 mihomo 的自查顺序

迁移重点不是重写所有规则，而是找到依赖旧内核的部分。大部分基础字段、传统节点与规则语句可以作为起点，但 Premium 的脚本配置、旧实验字段及特定 TUN 参数不应按原样保留。mihomo 不应被当作 Premium 脚本接口的直接替代品。

  1. 保存配置与运行环境：保留当前可用 YAML，记录监听端口、所选策略组、系统代理和 TUN 状态。订阅地址应保存在安全位置，不公开分享。
  2. 核对订阅输出目标：优先使用服务方提供的 mihomo 或 Clash Meta 格式。节点含 VLESS、Hysteria2 时，确认协议参数完整。
  3. 执行配置测试：运行 mihomo -t，先处理未知协议、字段类型、规则文件路径和策略名称错误。
  4. 只验证系统代理：关闭 TUN，通过明确端口验证节点与规则。例如实际端口为 7890 时，可让支持代理的应用使用 127.0.0.1:7890。
  5. 核对规则集：检查 behavior、format、本地文件内容和规则顺序，确认引用的策略组真实存在。
  6. 单独启用 DNS 与 TUN：按权限、接口、路由、解析的顺序定位。每次只修改一个变量，保留日志供前后对照。
  7. 验证客户端覆写：检查最终运行配置。客户端可能对端口、DNS、TUN 或规则做合并，编辑订阅源文件并不一定改变实际运行值。

用可复现条件比较速度

协议扩展不等于自动提速。比较两个内核时，应固定节点、测试目标、网络与时间窗口，并记录单连接下载速度、并发表现和 CPU 占用。延迟测试只反映指定目标的一次请求耗时；它不能替代大文件吞吐，也不能证明所有网站都走了同一条线路。

需要新增协议、持续更新的规则集能力或更细的 DNS 配置时，mihomo 是应重点核对的内核。只需要传统协议与简单系统代理时，选择重点仍是客户端维护状态、当前系统兼容性和配置是否易于管理。可在术语表核对 Fake-IP、策略组与规则集概念，再按配置教程逐步验证。

下载Clash