先区分客户端、内核与配置格式

mihomo 是网络代理内核，前身是 Clash Meta。它负责解析配置、建立出站连接、匹配规则和处理 DNS。客户端则提供配置导入、系统代理开关、TUN 模式、代理组选择与日志界面。客户端名称包含 Clash，不代表实际运行的内核就是原版 Clash，也不代表它能读取所有 mihomo 字段。

比较“原版 Clash”时，还要区分开源内核与历史上的 Clash Premium。两者曾有功能差异，尤其涉及 TUN、规则提供者等能力。因此，不能把所有扩展都写成“mihomo 首次支持”，也不能只凭旧客户端的界面判断内核能力。

  • 客户端版本：决定界面入口、权限管理和配置覆写方式。
  • 内核版本：决定协议类型、字段解析和网络功能是否可用。
  • 订阅格式：决定导入的是节点列表，还是包含 DNS、规则和代理组的完整配置。

协议扩展：能解析节点，不等于连接参数正确

相较原版开源 Clash，mihomo 扩展了多种出站协议与传输能力。常见迁移动机包括 VLESS、REALITY、Hysteria2 和 TUIC。具体可用字段仍取决于安装的内核版本；订阅转换服务若选择了旧 Clash 输出格式，也可能在导入前就丢失这些节点或参数。

能力mihomo 配置关注点常见迁移问题
VLESStype: vless、UUID、传输层与 TLS 参数订阅转换后类型被过滤，或传输参数不完整
REALITYTLS、servername、reality-opts公钥、短 ID 与服务端配置不匹配
Hysteria2type: hysteria2、认证、TLS 与 UDP 可达性网络限制 UDP，或错用第一代协议字段
TUICtype: tuic、认证与服务端协议版本客户端与服务端版本要求不一致

REALITY 不是独立的节点类型

不能把节点写成 type: reality 来代替 VLESS。常见组合是在 VLESS 节点中启用 TLS，并设置 reality-opts；若服务端采用 Vision，还要核对对应的 flow。节点能够显示在代理页，只说明配置已被读取，不代表认证与握手一定成功。

先验证一个节点，再迁移整组

  1. 确认订阅输出目标支持 mihomo 或 Clash Meta，而不是仅支持旧 Clash。
  2. 检查节点类型、服务器端口、认证字段和 TLS 参数是否完整。
  3. 先通过一个已知节点访问目标站点，再查看日志中的握手或认证错误。
  4. 涉及 Hysteria2、TUIC 时，另查 UDP 网络条件，不用 TCP 端口连通结果代替协议测试。

更新内核不会把旧节点自动转换成新协议，也不会更改服务端配置。新协议是否合适，取决于服务端支持与当前网络环境，而不是名称更新。

rule-providers：把规则来源与规则执行分开

rule-providers 用来管理独立规则集，再由 RULE-SET 在规则列表中引用。历史上的 Clash Premium 已有规则提供者能力，mihomo 在此基础上继续扩展规则格式与相关功能。因此，从普通开源 Clash 迁移和从 Premium 迁移，所需改动并不相同。

下面使用本地规则集，便于先排除远程下载失败。两个文件均为示例；主配置片段需要合并到现有配置中，不能覆盖后丢掉原有节点、代理组和 DNS 设置。

主配置片段

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

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

规则集文件：rules/local-direct.yaml

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

此例只展示规则引用，默认全部直连，并不是可直接使用的代理分流方案。path 按内核工作目录解析；图形客户端可能使用自己的配置目录，需要从运行配置或日志确认实际位置。

  • behavior: domain 用于域名规则集，内容不是完整的 DOMAIN-SUFFIX,... 规则行。
  • behavior: ipcidr 用于 IP 网段规则集，不能混入域名规则。
  • behavior: classical 可使用上例的传统规则条目，但仍需遵守内核支持的规则类型。
  • format 与真实文件格式必须一致。mihomo 的 mrs 格式用于 domain、ipcidr 类规则集，不能把任意 YAML 改后缀后当作 MRS。

规则仍按顺序匹配。若把 MATCH 放在 RULE-SET 前面，后面的规则集不会获得匹配机会。换用远程提供者后，还要分别检查下载是否成功、文件是否解析成功、请求是否命中规则，三者不是同一件事。

DNS 改动：区分访问域名与节点域名

mihomo 的 DNS 配置提供了更细的解析路径控制，例如 nameserver-policy、proxy-server-nameserver，以及让 DNS 连接遵循路由规则的相关选项。迁移时最容易出错的不是地址少填一个，而是 DNS 查询的出站依赖尚未解析的节点域名，形成循环依赖。

先建立最小可观察配置

下面片段展示 fake-ip 与节点域名解析的分工。127.0.0.1:1053 是本地 DNS 监听地址，不是系统代理端口；仅设置监听不会自动让所有应用使用它。示例中的公共解析器是否适用于当前网络，需要实际确认。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver 处理通常的域名解析；proxy-server-nameserver 专门用于代理节点的域名解析。上例把两者指向同一解析器，是为了展示字段职责，并非推荐所有环境都照用这个地址。使用加密 DNS 时，还要核对解析器自身域名的引导解析与网络可达性。

fake-ip-filter 不是直连规则

fake-ip 模式会向应用返回合成地址，再由内核维护地址与域名的映射。将域名加入 fake-ip-filter，表示让它避开 fake-ip 分配，不代表该连接一定直连。最终出站仍由规则、代理组和出站模式决定。

迁移初期不宜同时更换上游 DNS、开启 TUN、启用嗅探并重写全部规则。建议先确认 DNS 能得到预期响应，再检查连接是否命中正确规则。需要启用 respect-rules 时，应先把节点域名解析路径配置清楚，并核对当前版本文档，避免 DNS 请求反过来依赖尚未建立的代理。

嗅探：补充域名信息，不是解密 HTTPS

当流量进入内核时只剩目标 IP，域名规则可能缺少匹配依据。mihomo 的 sniffer 可以根据 HTTP Host、TLS 握手中的服务器名称等信息尝试识别域名。它不需要因此解密 HTTPS 正文，也无法保证从每一条加密连接中都提取到域名。

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

示例仅在指定端口尝试 HTTP 与 TLS 嗅探，没有开启目的地址覆盖等附加行为。若服务运行在其他端口，需要按实际情况调整。不要把旧配置中的历史嗅探字段直接拼到新结构中；字段层级不匹配时，应以当前内核的配置检查结果为准。

  • 适合检查的场景：TUN 接收到 IP 连接，但预期按域名分流。
  • 不能替代的设置：DNS 配置、代理组定义、路由排除和应用自身的代理设置。
  • 需要留意的限制：ECH 等机制可能隐藏可见服务器名称，部分流量也没有可识别的域名。

若开启嗅探后特定站点行为变化，先针对该域名调整嗅探范围或暂时关闭功能，再比较连接日志。不要用扩大嗅探端口范围来掩盖 DNS 和路由问题。

TUN 与系统代理：内核更新不等于入口自动切换

系统代理依赖应用遵循操作系统代理设置。TUN 模式通过虚拟网卡接入 IP 流量，需要客户端正确处理权限、路由和 DNS。mihomo 支持 TUN，但不同平台、客户端和版本的接入方式不同，不能仅复制一段 tun: 配置就认定已经接管全部流量。

例如，本地混合端口设为 7890 时，遵循系统代理的应用可通过该端口进入内核。DNS 监听 1053 则属于另一条入口。两个端口职责不同，不应把系统 HTTP 代理地址填写成 DNS 监听端口。

初次迁移可先关闭 TUN，用系统代理验证订阅与节点，再单独启用 TUN。出现局域网、打印机或其他 VPN 访问异常时，重点检查路由重叠、DNS 接管与排除项，而不是先怀疑节点协议。

旧配置迁移：按语法、资源、连接三层排查

第一层：检查最终运行配置

先备份订阅文件、自定义覆写和代理组选择。客户端可能在启动内核前合并多个来源，因此编辑器里看到的文件不一定是最终运行配置。应检查客户端导出的运行配置，确认 dns、rules 和 proxy-groups 没有被覆写成另一套内容。

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

-t 用于配置检查。通过检查说明内核能够接受配置，不等于远程规则一定下载成功，更不等于节点可以连接。使用客户端托管内核时，优先用客户端提供的检查入口，避免调用到另一份版本不同的二进制。

第二层：确认外部资源与名称引用

  1. 检查代理组引用的节点或提供者是否存在，名称是否完全一致。
  2. 检查 RULE-SET 的名称是否对应 rule-providers 中的键。
  3. 查看规则文件路径、远程资源请求和解析错误，区分网络失败与格式不符。
  4. 确认订阅更新后自定义配置仍然生效，不要只修改会被下次更新覆盖的缓存文件。

第三层：用固定请求验证结果

在混合端口确实为 7890、内核已经运行的前提下，可用下面命令显式通过 HTTP 代理发起请求，避免测试工具是否遵循系统代理带来的歧义。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

这里的 10 秒与 20 秒分别限制连接等待和整个请求时长，不是速度评分。测试后在连接页核对目标域名、命中规则和实际出站；出现错误则到日志页查看具体原因。握手失败先查节点参数，规则不符先查顺序与域名信息，没有连接记录则先查入口。

迁移的完成标准是：配置检查通过、所需资源加载成功、应用流量进入内核、规则命中符合预期、节点连接正常。按这五项逐步确认，比一次启用所有新功能更容易定位问题，也便于保留可恢复的旧配置。