先给结论：旧配置通常能迁移，新能力不能反向通用
如果订阅仍是常见的 Shadowsocks、VMess 或 Trojan 节点，规则主要使用 DOMAIN-SUFFIX、IP-CIDR 和 MATCH，迁移到 mihomo 通常不必重写整份 YAML。真正需要逐项检查的是节点扩展参数、规则集格式、DNS 配置，以及客户端是否会覆盖手动修改的字段。
mihomo 是 Clash Meta 项目后续使用的名称，延续了 Clash 的配置体系，并持续扩展协议和流量处理能力。它是内核，不等于某一个带界面的 Clash 客户端。客户端负责订阅管理、系统代理开关和配置合并；内核负责建立连接、执行规则与处理 DNS。只更换界面程序，未必就更换了实际运行的内核。
原版项目已停止维护。需要新协议、持续更新的规则能力或较新的系统适配时，应优先评估仍在维护的内核；但“内核更新”不等于所有节点都会更快。线路质量、服务端配置、网络丢包和实际命中的出站策略，仍然直接影响连接表现。
协议支持：先看节点类型，再看握手参数
| 节点或能力 | 原版 Clash 开源内核 | mihomo 迁移检查 |
|---|---|---|
| Shadowsocks、VMess、Trojan | 支持常见配置 | 核对加密方式、传输层与 TLS 参数 |
| VLESS、Reality | 不支持对应的新式组合 | 确认服务端要求的 flow、指纹、公钥与 short-id |
| Hysteria2、TUIC | 不支持 | 检查 UDP 连通性及协议专属认证字段 |
| 较新的加密与传输扩展 | 受历史版本限制 | 按具体算法、传输类型及内核版本核对 |
“支持 VLESS”不代表任意 VLESS 链接都能直接使用
节点的 type 只是第一层。VLESS 配合 Reality 时，还可能涉及 servername、client-fingerprint、reality-opts 下的公钥与短标识；使用 Vision 时还要核对 flow。这些参数需要与服务端相符，不能从另一个节点复制后继续沿用。
- 报“不支持的代理类型”：先检查实际内核是否为 mihomo，而不是只看客户端名称或订阅文件名。
- 配置通过但 TLS 握手失败：检查系统时间、SNI、证书域名和 Reality 参数，不要先关闭证书验证。
- Hysteria2 或 TUIC 超时：确认当前网络与服务端允许 UDP。浏览器能通过其他 TCP 节点打开网页，并不能证明 UDP 链路正常。
订阅转换也有边界：转换工具能够调整字段结构，不能把一个 Hysteria2 服务端自动变成原版 Clash 支持的 VMess 服务端。遇到客户端不识别的新协议，应更换兼容内核或使用服务提供方明确支持的其他节点。
规则扩展：基础语法保留，规则集需要核对格式
Clash 的常用规则仍按列表从上到下匹配，首条命中后选定出站策略。迁移时可以先保留已有规则顺序，不要同时调整几十条规则。尤其要确保规则引用的策略组实际存在，最后再用 MATCH 接住前面未命中的连接。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,Proxy这里的 Proxy 必须是配置中已有的策略组或出站名称；example.com 是用于展示语法的保留示例域名。no-resolve 表示这条 IP 规则不主动触发域名解析，并不表示关闭整个内核的 DNS。如果连接本来就有目标 IP，仍可按该 IP 匹配。
rule-providers 与 RULE-SET 不是同一层概念
rule-providers 定义规则从哪里读取、如何解释；RULE-SET 则在主规则列表中引用它。mihomo 支持规则提供器，也提供更多规则组合与匹配能力；Premium 用户可能已经使用过其中一部分机制。
rule-providers:
private-net:
type: file
behavior: classical
format: yaml
path: ./rules/private.yaml
rules:
- RULE-SET,private-net,DIRECT
- MATCH,Proxy对应的 ./rules/private.yaml 文件可以包含下面的内容。相对路径通常基于内核工作目录，不一定是界面程序所在目录；找不到文件时先查看启动日志中的工作路径。
payload:
- IP-CIDR,10.0.0.0/8,no-resolve
- IP-CIDR,172.16.0.0/12,no-resolve
- IP-CIDR,192.168.0.0/16,no-resolvebehavior: classical接受带规则类型的条目，例如上面的IP-CIDR。behavior: domain和behavior: ipcidr使用各自对应的内容格式，不要直接混入整行 classical 规则。- mihomo 的 MRS 二进制规则集用于 domain 或 ipcidr 类型，不能把任意 classical YAML 改个扩展名就当作 MRS。
- 逻辑规则、进程匹配等扩展应逐项验证。进程识别还受到操作系统、权限和流量接管方式影响。
如果迁移后大量网站都进入兜底策略，先看规则集是否加载成功，再检查规则顺序。规则集地址能够下载，不代表其内容格式与 behavior 一致。
DNS 差异：保留基础字段，分开验证解析与出站
原版 Clash 已有 DNS 模块和 Fake-IP 等基础能力，mihomo 在此基础上扩展了按域名选择解析器、节点域名解析等控制方式。DNS 返回正确地址与连接走对策略是两件事：前者决定访问哪个目标，后者决定通过哪个出口连接。
旧配置可以先保留哪些字段
常见的 dns.enable、listen、enhanced-mode、fake-ip-range 与 nameserver 可以作为迁移起点。下面只是便于理解的 DNS 片段，不包含完整节点和策略组，也不会自动修改系统 DNS。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.291053 是此示例的本地 DNS 监听端口；普通系统 DNS 设置通常只填写服务器地址，不能顺带填写这个端口。若要接管系统解析，需要另行配置转发或在适用场景启用 TUN 的 DNS 劫持。198.18.0.1/16 属于 Fake-IP 映射用途，不是远端网站的真实公网地址。
新能力不要一次性全部打开
- nameserver-policy：为指定域名或域名集合选择解析器，适合分开处理内网域名与公网域名。
- proxy-server-nameserver：为代理节点的服务器域名指定解析路径，避免解析节点地址时又依赖尚未建立的代理。
- fake-ip-filter：对确有兼容性问题的域名排除 Fake-IP；不要为了一个局域网服务直接取消整套分流方案。
验证时应分别检查客户端 DNS 日志、连接详情中的域名和最终策略。浏览器自带的安全 DNS 可能使用独立解析路径；仅修改内核 DNS，不足以证明浏览器的每次查询都经过它。
TUN 与流量嗅探：接管范围不同于规则模式
系统代理主要服务于愿意读取系统代理设置的应用；TUN 通过虚拟网络接口接管流量，适合处理不读取系统代理的程序。TUN 是流量进入内核的方式，规则模式则决定流量进入后如何选择出站，两者不是互斥选项。
原版开源内核不能与 Premium 的 TUN 能力混为一谈。迁移到 mihomo 后，也不能仅复制一段 tun 配置就认为全部生效：客户端可能要求安装服务、授予管理员权限，或者由图形界面生成并覆盖相应字段。
- 先用系统代理验证订阅、节点和规则，不要在配置尚未通过时叠加 TUN。
- 关闭其他 VPN 或虚拟网卡工具进行对照，避免默认路由竞争。
- 启用 TUN 后查看日志中的虚拟接口和路由创建结果，确认不是权限失败。
- 测试局域网打印机、NAS 和公司内网地址，必要时配置明确的绕过规则或路由排除。
mihomo 的流量嗅探能够在部分 HTTP、TLS 或 QUIC 流量中提取主机信息，辅助域名规则匹配，但它不等于解密 HTTPS 内容，也不能保证识别所有连接。加密 ClientHello 等机制可能限制可见信息。嗅探配置应围绕具体分流需求开启，而不是作为所有 DNS 问题的统一补丁。
旧订阅迁移：按配置来源逐项处理
| 配置部分 | 通常怎样处理 | 必须检查什么 |
|---|---|---|
| mixed-port、mode、log-level | 可以先沿用 | 端口冲突、客户端覆盖值 |
| proxies、proxy-groups | 基础结构保留 | 协议字段、组内节点名称、测试地址 |
| rules | 常见规则保留 | 引用名称、顺序、MATCH 位置 |
| rule-providers | 核对格式后复用 | behavior、format、文件路径及加载结果 |
| dns、tun | 分阶段启用 | 系统权限、路由、解析依赖与界面合并 |
| Premium script 脚本规则 | 不能按原样兼容推定 | 改写为 mihomo 支持的规则或规则集 |
实际迁移顺序
- 备份原始配置：分别保存订阅原文和客户端当前生成的运行配置。两者可能不同，排查时不要只查看订阅编辑器。
- 确认内核身份：在客户端的内核信息或启动日志中查看名称与版本。使用独立二进制时，运行
mihomo -v查看版本。 - 先做配置测试：在配置所在目录运行
mihomo -t -f ./config.yaml。Windows 独立可执行文件可使用.\mihomo.exe -t -f .\config.yaml。 - 只接通一条路径：先选一个已知可用节点，启用系统代理，用规则模式访问测试页面。
- 逐项恢复扩展：按规则集、DNS 策略、TUN 的顺序启用，每次只改一类配置并查看日志。
- 最后更新一次订阅：确认自定义规则没有丢失，再设置自动更新与开机启动。
配置测试通过只能说明内核能够读取配置，并不保证订阅节点在线、规则集下载成功或系统代理已开启。带界面的客户端还可能在启动前合并配置，因此命令行测试使用的文件应尽量与客户端实际运行文件一致。
迁移后的验证：端口、规则、DNS 分开检查
假设运行配置的 mixed-port 为 7890，可以先通过显式代理测试。这能够绕开系统代理是否设置正确这一变量；端口应替换为客户端实际显示的值。
curl -I --proxy http://127.0.0.1:7890 https://example.comWindows PowerShell 中可使用 curl.exe，避免部分环境中的同名命令别名影响参数解析。该测试只验证这次 HTTP 代理请求，不代表 UDP、TUN 或其他应用也已正常。
- 提示连接被拒绝：优先检查内核是否启动、本地端口是否正确，以及是否被其他进程占用。
- 代理可连接但请求超时：检查所选节点、节点域名解析及服务端可达性。
- 页面能打开但出口不符：在连接详情中核对命中规则、策略组当前选择，以及是否实际处于全局模式。
- 只有某个应用失败：确认它是否读取系统代理；确实不读取时，再评估 TUN，而不是反复更换订阅。
最终选择可以很直接：需要 VLESS Reality、Hysteria2、TUIC 或更细的规则与 DNS 控制，使用匹配这些能力的 mihomo 客户端；迁移基础订阅时，则先复用稳定配置。把内核兼容、配置合并和网络连通性分开验证，比一次性替换所有设置更容易定位问题。
具体字段可继续查阅Clash 配置手册；遇到端口占用、系统代理不生效或权限问题，可对照常见问题逐项检查。