先确认内核：客户端名称不等于功能范围
订阅导入后提示 unsupport proxy type，或配置里写了 sniffer 却看不到预期效果，先不要改节点密码。最先确认的是：客户端实际启动了哪一个内核。界面负责订阅管理、系统代理和开关操作，内核负责解析配置、匹配规则与建立连接；界面名称相近，不代表它们支持同一套字段。
这里把“原版 Clash”拆成两个对象：原版开源内核，以及曾独立分发的 Clash Premium。Premium 的 TUN、规则集等能力不能直接算到原版开源内核上。mihomo 则由 Clash Meta 演进而来，继承了大量 Clash 配置习惯，但不是只改了程序名称。
- 桌面客户端：查找「关于」中的内核版本信息，并查看启动日志。不同客户端的菜单名称不完全一致，以实际界面为准。
- 命令行部署：对实际运行的二进制执行
mihomo -v；不要只查看下载目录中另一份程序的版本。 - 路由器或容器：同时确认插件所选内核、容器镜像和进程路径。更新管理界面不一定会更新内核。
协议支持：VLESS、Hysteria2、TUIC 是主要区别
如果现有订阅只包含传统 Shadowsocks、VMess、Trojan 节点，迁移时可能看不出明显变化。真正容易触发兼容性报错的是新协议、新加密方法，以及协议附带的传输参数。节点名称写着“Hysteria2”没有意义，内核读取的是 YAML 中的 type 和相关字段。
| 协议或能力 | 原版 Clash | mihomo |
|---|---|---|
| Shadowsocks、VMess、Trojan | 常见基础协议可用，具体参数取决于版本 | 支持，并有后续扩展 |
| VLESS | 原版开源及 Premium 不提供该协议 | 支持，节点类型为 vless |
| Hysteria2 | 不支持 | 支持，节点类型为 hysteria2 |
| TUIC | 不支持 | 支持，节点类型为 tuic |
| VLESS 配合 REALITY | 不支持 | 支持相应配置，但服务端参数必须匹配 |
报错发生在哪一步，决定先查什么
如果配置测试直接报“不支持的代理类型”，问题在本地解析阶段，尚未进入节点连通性测试。反过来，配置加载成功却出现连接超时，不能据此认定协议不支持。应继续检查服务器地址、端口、认证信息以及传输网络。
- VLESS：核对 UUID、TLS、
servername、传输方式与flow。使用 REALITY 时，还要核对公钥和 short ID 等对应参数。 - Hysteria2：基于 QUIC，依赖 UDP 可达。只测试服务器 TCP 端口，不能证明这条节点可用；也不要把 Hysteria 第一代配置直接改名后使用。
- TUIC：同样需要关注 UDP 网络条件，且认证字段必须与服务端协议版本匹配。不能用客户端支持 TUIC 作为服务端参数正确的证据。
订阅转换也有边界。转换器可以重排字段，却不能给旧内核补上协议实现。若转换后节点消失，先检查输出是否选择了面向 mihomo 的格式，以及转换服务是否支持该协议，不要反复更新同一份不兼容订阅。
规则集对照：rule-providers 不是 mihomo 独有概念
rule-providers 用来声明规则集来源，RULE-SET 用来在规则列表中引用它。原版开源 Clash 与 Premium 的能力在这里有明显区别：Premium 已有规则集支持，不能把所有规则集功能都称为 mihomo 新增。mihomo 在此基础上提供了更多格式和使用方式。
| 配置项 | 迁移时的判断 |
|---|---|
rules |
基础规则列表仍按自上而下顺序匹配，第一条命中即采用对应策略。 |
rule-providers |
Premium 已支持；原版开源内核不能按 Premium 能力推断。 |
behavior |
区分 domain、ipcidr、classical，内容必须匹配声明。 |
format: mrs |
属于 mihomo 的规则集格式能力，适用于 domain、ipcidr，不适用于 classical。 |
type: inline |
mihomo 可将规则内容直接写入 provider 的 payload；旧内核不能默认兼容。 |
先用本地 YAML 验证规则集链路
下面是一段可合并进 mihomo 配置的规则示例。它不依赖远程下载，便于区分“规则写错”和“规则文件获取失败”。配置只使用内置策略 DIRECT 与 REJECT，不依赖尚未定义的节点组。
rule-providers:
local-block:
type: file
behavior: domain
format: yaml
path: ./rules/local-block.yaml
rules:
- RULE-SET,local-block,REJECT
- MATCH,DIRECT在配置工作目录下建立 rules/local-block.yaml，写入以下内容。这里的 example.org 是用于演示规则行为的保留域名，测试时应预期该域名及其子域被拒绝。
payload:
- '+.example.org'behavior: domain 的内容是域名匹配项，不要在其中写 DOMAIN-SUFFIX,example.org。若采用 classical，才按相应规则类型书写，例如 DOMAIN-SUFFIX,example.org，且规则集内部不附加最终出站策略。
sniffer 与 DNS：域名识别不等于流量解密
迁移后某些连接由 IP 规则改为域名规则命中，常常与 DNS 映射或嗅探有关。mihomo 的 sniffer 可从部分协议握手中提取主机名，例如 HTTP 的 Host、TLS 的 SNI，以及受支持的 QUIC 握手信息。它不是安装证书的 HTTPS 中间人解密，也不保证每条连接都能识别域名。
先观察，再决定是否开启覆盖目标
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
override-destination: false
TLS:
ports: [443, 8443]
override-destination: false这段示例只列出 HTTP 与 TLS，不代表所有端口都需要嗅探。override-destination: false 表示不据此覆盖连接目标；嗅探信息仍可能参与域名识别与规则判断。是否覆盖目标需要结合 DNS 和应用行为测试，不能当作必开的优化开关。
- 域名识别失败：可能是连接未经过配置的端口、握手不含可用域名，或应用使用了隐藏相关信息的机制。
- 应用直连目标 IP：嗅探不一定能恢复域名，应保留必要的 IP 规则，不能只留下域名规则。
- 网站被错误分流：同时检查规则顺序、DNS 返回结果、fake-ip 映射与 sniffer 设置，不要一开始就扩大嗅探范围。
dns.enhanced-mode: fake-ip 与 redir-host 是不同的处理方式，fake-ip 也不是 mihomo 独有。迁移时先保留原来的 DNS 模式；如需调整，再单独修改并清理相关 DNS 缓存。内核 DNS 监听地址还必须与系统或接管链路对接，仅写一个 dns.listen 不代表系统请求已经进入它。
TUN 与端口：配置兼容不代表接管路径相同
浏览器能访问，但游戏、命令行或其他应用不走代理，通常应检查流量入口，而不是立即更换协议。系统代理主要影响遵守该设置的应用；TUN 通过虚拟网络接口接收流量，可以覆盖更多应用，但还涉及权限、路由和 DNS 接管。
原版 Premium 已提供 TUN，原版开源内核不能与它混为一谈。mihomo 也提供 TUN，但不能保证旧配置中的栈选择、接口参数和路由设置在所有系统上原样工作。Windows、macOS、Linux 的权限和服务管理方式存在差异。
迁移时分两轮验证
- 先关闭 TUN，使用显式代理确认节点与规则正常。例如配置
mixed-port: 7897后，对应入口为127.0.0.1:7897；7897 是此处示例值，不是所有客户端的固定端口。 - 在终端执行下方命令，确认请求确实经过该入口。测试地址仅用于检查基本 HTTPS 连接，不能代表所有目标网站都可用。
- 显式代理正常后，再在客户端启用 TUN。检查提权或服务状态，以及虚拟接口和路由是否建立，最后测试不读取系统代理的应用。
curl --proxy http://127.0.0.1:7897 --connect-timeout 10 -I https://example.com遇到 address already in use，先检查是否同时运行了两份内核。迁移期间旧客户端未退出，是本地监听端口冲突的常见原因。若出现整机断网，先关闭新客户端的 TUN 和系统代理，恢复基本网络，再逐项排查，不要同时叠加多个 VPN 或路由接管工具。
配置迁移步骤：测试、加载、规则与连通性分开验收
一份配置“能被加载”，只说明它通过了当前阶段的解析与初始化，不说明所有字段都被使用，更不代表节点和 DNS 已经可用。部分未知字段可能未产生显眼报错，因此应同时检查运行日志和实际行为。
- 备份当前状态。保存原始订阅、合并后的运行配置，以及本地覆写文件。订阅链接和节点认证信息不要发到公开讨论区。
- 选择匹配的订阅格式。订阅服务若提供 Clash 与 Clash Meta/mihomo 两种输出，按实际内核选择；检查生成结果，不只看按钮名称。
- 先执行配置测试。使用实际部署的二进制，并指定配置文件和工作目录，避免相对路径指向错误位置。
- 验证入口与节点。先通过显式代理测试，再查看连接记录中选择的节点或策略组；连接失败时保留完整报错链。
- 验证规则集。检查 provider 是否成功加载、条目是否存在，以及测试域名实际命中了哪条规则。
- 最后启用增强功能。每轮只改 DNS、sniffer、TUN 中的一项。出现异常时，能明确回退到上一份可用配置。
mihomo -v
mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml上面的 /srv/mihomo 是 Linux 部署示例目录，执行前应确认文件确实位于该目录。Windows 可使用 mihomo.exe -t -d . -f .\config.yaml 在当前配置目录测试。由客户端管理内核时，最终生效文件可能由订阅与覆写合并生成，不能只测试一份未被使用的原始文件。
如何选择：按节点协议与维护需求判断
需要 VLESS、Hysteria2、TUIC、MRS 规则集或 sniffer 等能力时，mihomo 的功能范围更符合需求。若只是维护一套传统协议配置，迁移重点则是配置可验证、客户端仍在维护，以及出现问题后能定位到具体环节，而不是期待更换内核就自动降低延迟。
- 已有配置稳定：保留备份，先在独立测试窗口验证新内核，不同时修改节点、规则与 DNS。
- 订阅提示协议不支持：确认生成格式与实际运行内核，再决定是否切换客户端或内核。
- 路由器资源有限：关注规则集体积、加载耗时与设备可用内存；格式选择不能代替实际运行观察。
- 准备从 mihomo 回迁：逐项移除目标内核不支持的协议与字段，再重新做配置测试和连通性验收。
两者差别可以按三层记忆：协议决定节点能否被识别，规则与 DNS 决定连接如何分流，系统代理或 TUN 决定流量能否进入内核。按这三层逐项检查，比同时切换多个开关更容易找到原因。