内核范围：先区分原版、Premium 与 mihomo

mihomo 是原 Clash.Meta 项目的后续名称，也常被称为 Clash Meta 内核。它延续 Clash 的 YAML 配置体系，同时扩展协议、DNS、规则集和流量接管能力。更换到搭载 mihomo 的客户端，不等于只更换一个界面：实际解析配置、建立连接与执行规则的程序已经改变。

“原版 Clash”需要拆成两个比较对象：Dreamacro/clash 开源内核，以及原版生态中的 Clash Premium。两者的功能并不完全相同。尤其是 TUN 与规则提供者，不能简单归类为“原版没有、mihomo 才有”。原版项目在 2023 年停止维护后，旧教程和订阅模板仍在流通，迁移时应以实际内核版本为准。

  • 客户端：负责订阅导入、托盘、系统代理和配置生成，例如桌面端的配置管理界面。
  • 内核：负责协议握手、DNS 查询、规则匹配与出站连接；界面版本号不能代替内核版本号。
  • 订阅：可能是完整配置，也可能只是一组节点；两者不能随意放进同一种提供者字段。

功能对照：协议扩展不等于配置完全通用

比较项原版 Clash 系列mihomo
常见代理协议支持 Shadowsocks、VMess、Trojan 等，具体能力取决于版本保留常见协议，并扩展 VLESS、Hysteria2、TUIC 等
VLESS 与 REALITY原版内核不能直接使用相应的 mihomo 配置支持相关组合，需同时匹配传输、TLS 与服务端参数
rule-providersPremium 提供规则集能力，不能泛化到所有开源原版构建支持规则提供者，并有更多格式与行为选项
域名嗅探没有与 mihomo 完全对应的 sniffer 配置体系可从受支持流量的协议元数据中尝试提取域名
TUN 接管Premium 有相关能力，平台与版本存在差异支持 TUN，实际接管仍依赖权限、路由与系统环境
基础分流规则常见 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等沿用基础语法，并扩展规则类型与组合方式

该表说明的是能力边界，不是任何版本都适用的承诺。服务端新特性、特定传输组合以及规则集格式可能要求较新的 mihomo。遇到“不支持的代理类型”，先检查客户端当前运行的内核，不要只看安装包名称中是否出现 Meta。

VLESS、Hysteria2 的迁移检查点

VLESS 的节点类型写作 type: vless。若服务端使用 REALITY，还需要正确的 reality-opts、公钥、短 ID、服务器名称及匹配的客户端指纹；flow 也必须与服务端配置相符。仅把原 VMess 节点的类型改成 VLESS，不会完成协议转换。

Hysteria2 的节点类型写作 type: hysteria2，它与 Hysteria 第一代不是同一种配置。认证值、端口、SNI、混淆与带宽参数需要按服务端填写；所处网络也必须允许对应的 UDP 通信。TCP 网页可以打开，不代表 Hysteria2 的 UDP 握手一定可达。

  • 优先向订阅提供方获取 mihomo 适用的输出格式，而不是反复手改完整订阅。
  • 不要通过全局设置 skip-cert-verify: true 掩盖证书名称或信任链错误。
  • 节点含密码、UUID 或认证令牌。提交日志前先脱敏，订阅 URL 中的令牌也需要删除。

规则集迁移：区分 provider、behavior 与文件内容

proxy-providers 提供节点，rule-providers 提供匹配条件。前者通过策略组的 use 引用，后者通过 RULE-SET 规则引用。把一份节点订阅地址填入规则提供者，即使地址能下载，也无法得到可用的分流规则。

下面是一组本地文件示例。配置文件和 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'
  - 'example.org'

behavior: domain 的条目是域名模式，不能在其中直接塞入 DOMAIN-SUFFIX,example.com 这样的完整规则。若使用 behavior: classical，则可以在 payload 中写受支持的经典规则条目，例如 DOMAIN-SUFFIX,example.com；执行策略由外层的 RULE-SET 指定。

  • domain：用于域名匹配内容，适合纯域名列表。
  • ipcidr：用于 IP 网段内容，例如 192.168.0.0/16，不要混入域名。
  • classical：用于受支持的经典规则类型，内容格式与前两者不同。

YAML、纯文本和 MRS 是不同的存储格式。MRS 是 mihomo 的二进制规则集格式，支持 domain 与 ipcidr 行为，不适合直接作为原版内核的通用交换格式。迁移时同时核对 behavior、format 和远端实际返回内容；把文件后缀改为 .yaml 不会改变内部格式。

规则仍然按顺序匹配。将 MATCH 提前，会让后续规则无法生效；把范围很大的直连规则放在代理规则前，也可能改变原有分流。加载成功只证明内容可解析，不能证明命中顺序符合预期。

sniffer 嗅探：补充域名线索，不是解密流量

部分连接进入内核时只有目标 IP。mihomo 的 sniffer 可以在受支持的 HTTP、TLS、QUIC 流量中尝试获得域名线索，辅助规则匹配；相关选项还可能改变连接目标。它不是 HTTPS 解密代理，不会因此获得 TLS 加密后的正文，也不能保证从每个连接中提取域名。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]
    QUIC:
      ports: [443]

这段配置把 HTTP 检查限制在 80、8080 端口，把 TLS 与 QUIC 检查限制在 443 端口，并显式关闭目标地址覆盖。这样便于先观察嗅探与规则匹配结果，避免同时引入目标改写变量。是否扩大端口范围，应按业务需要决定，不宜为了“更完整”直接检查所有端口。

遇到特定网站开启嗅探后异常，先关闭 sniffer.enable 做单变量比较，再检查相关域名是否需要加入 skip-domain。TLS 使用 ECH 等机制时，可观察到的域名信息可能减少。嗅探也不能替代 DNS 分流：客户端 DNS 从系统绕行的情况，仍需在 DNS 或接管链路上处理。

DNS 与 TUN：基础字段保留，运行条件需要重查

旧配置中的 dns.enable、enhanced-mode: fake-ip、fake-ip-filter 等概念仍可在 mihomo 中使用。Fake-IP 通过保留地址映射域名，再在后续连接中恢复相应的域名信息；它不等同于“所有 DNS 都经过代理”，也不会自动接管浏览器独立启用的加密 DNS。

新增 DNS 字段不能孤立复制

nameserver-policy 用于让特定域名使用指定解析器；proxy-server-nameserver 用于代理节点服务器域名的解析；respect-rules 可让 DNS 上游连接遵循路由规则。启用后需要关注代理节点域名的独立解析路径，避免“先建立代理才能解析节点、先解析节点才能建立代理”的循环依赖。

迁移初期建议先保留已知可用的 DNS 上游，仅验证域名能否解析、目标规则是否命中，再逐项引入这些字段。不要把两个客户端的 DNS 片段整体拼接：同名键可能被后者覆盖，客户端还可能在启动前注入自己的监听地址或策略。

TUN 失败通常不只是 YAML 语法问题

  • 权限：创建虚拟网卡、修改路由可能需要管理员权限、系统服务或相应的网络权限。
  • 路由：自动路由需要与 VPN、虚拟机网络及其他接管软件协调，避免双重接管。
  • DNS 劫持：dns-hijack 中的 53 端口规则不等于接管所有 DoH、DoT 请求。
  • 系统代理：供遵循系统代理设置的应用使用；TUN 在虚拟网卡层接管，两者不是同一个开关。

排查时先关闭 TUN，通过明确指定的本地代理端口测试节点，再单独启用 TUN。这样可以把“节点不可用”和“系统接管失败”分开，避免在路由故障上反复修改节点密码。

旧配置迁移：按最小配置、规则、接管依次验证

迁移不应从一次性复制所有高级字段开始。先记录原客户端的监听端口、工作模式、策略组选择及内核版本，再建立一份可以回退的副本。以下步骤适用于手动检查内核，也适用于定位客户端生成配置的问题。

  1. 确认实际内核。独立运行环境可执行 mihomo -v。客户端环境则查看内核信息或启动日志，区分客户端版本与内核版本。
  2. 检查配置语法。在配置目录执行 mihomo -t -f ./config.yaml。若文件提供者使用相对路径，同时确认内核的工作目录设置；语法检查通过不代表远端节点连接成功。
  3. 固定本地入口。例如使用 mixed-port: 7890，并保持 allow-lan: false。7890 是本例端口，不是所有客户端的固定默认值。
  4. 验证单个节点。先选定一个已知可用节点，通过本地代理请求目标，再启用自动策略组，避免健康检查与节点切换掩盖问题。
  5. 恢复规则与 DNS。逐个启用规则提供者，查看连接记录中的命中规则、策略组和最终节点，不只观察网页是否打开。
  6. 最后启用 TUN 与嗅探。每次只改变一个功能，并保留失败前后的日志与有效配置。
mihomo -v
mihomo -t -f ./config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

以上 curl 命令是在本机安装 curl 的前提下，显式通过 7890 端口发送请求。Windows PowerShell 中若 curl 被映射为其他命令，可使用 curl.exe。返回 HTTP 响应说明这次请求链路可以工作，但不证明所有域名、UDP 或 TUN 流量都正常。

需要优先检查的旧写法

  • 旧式键名：早期模板中的 Proxy、Proxy Group、Rule 应按当前配置结构整理为 proxies、proxy-groups、rules，不要依赖历史兼容处理。
  • 策略组引用：rules 中引用的组名必须存在，大小写和空格都应一致；删除旧组后也要修改最终的 MATCH。
  • 协议专有字段：不要把其他内核的 JSON 字段直接粘进 mihomo YAML。相同协议在不同配置体系中，字段层级和命名可能不同。
  • 控制接口：external-controller 与代理监听端口用途不同。只供本机管理时绑定回环地址；如需远程访问，应设置认证并限制网络访问范围。

故障判断：加载成功、连接成功与分流正确分开看

现象优先检查验证动作
不支持的代理类型实际运行的内核与订阅输出格式核对内核版本，并检查节点的 type 字段
规则提供者加载失败文件路径、返回内容、behavior 与 format打开实际文件，确认不是错误页面或节点订阅
配置通过但节点超时地址、端口、认证、TLS 与 UDP 可达性固定单个节点测试，不同时开启自动切换
手动代理正常，TUN 异常权限、路由、DNS 接管及其他 VPN关闭冲突接管，分别测试域名和 IP 连接
重启后修改消失订阅更新和客户端配置合并将自定义部分移入客户端持久化覆写机制

mihomo 的主要价值在于协议覆盖与配置能力扩展，而不是让旧配置在任何环境下自动等价运行。稳定迁移的判断标准也不是“界面没有报错”：应分别确认节点连接、DNS 解析、规则命中与系统接管，再恢复日常订阅更新。客户端选择可参考客户端对比，首次安装与系统权限设置可查阅全平台指南。