先分清客户端、内核与配置
遇到“订阅导入成功，但节点不能用”，先别急着更换订阅。图形客户端负责订阅管理、界面和系统设置，内核负责解析配置、建立代理连接、执行分流。界面能展示一个节点名称，并不代表后台内核理解它的协议。排查时应先查看客户端日志中的内核名称与版本，而不是只看客户端窗口里的版本号。
mihomo 是原 Clash Meta 项目更名后的内核，沿用 Clash 配置体系并继续扩展。讨论“原版 Clash”时还要区分历史上的开源内核与闭源 Premium 内核：它们的功能并不完全相同，尤其是规则提供器和 TUN。把两者混在一起，就容易得出“旧 Clash 完全没有规则集”这样的错误结论。
| 比较对象 | 需要确认的边界 | 迁移时的影响 |
|---|---|---|
| 原版开源 Clash | 历史开源分支的协议与配置能力 | 不能按 mihomo 的字段集合直接套用 |
| Clash Premium | 历史闭源增强版，曾提供规则集、TUN 等功能 | 部分功能概念相近，字段与行为仍需复核 |
| mihomo | 原 Clash Meta，扩展协议、规则与网络接管能力 | 保留大量常用写法，但并非所有旧配置都可原样运行 |
如果直接运行独立内核，可以用 mihomo -v 查看版本。图形客户端则应在内核信息或启动日志中确认实际加载的二进制文件；升级了界面程序，不一定就已经切换到预期内核。
新增协议：节点能否使用的第一道边界
相对历史原版 Clash，mihomo 的直接变化之一，是支持更多代理协议及其传输组合，例如 VLESS、Hysteria2、TUIC。它们不是同一种协议的不同名称，也不能仅通过修改配置中的 type 相互转换。服务端部署什么协议，客户端就必须按对应协议填写认证、传输和 TLS 参数。
VLESS 与 REALITY 要分别看
VLESS 是代理协议，REALITY 是相关连接中可使用的安全机制，二者不是同义词。一个 VLESS 节点可能使用普通 TLS，也可能采用 REALITY；不同组合还可能涉及 network、servername、flow、reality-opts 等字段。服务端提供了哪些参数，就按其配置要求填写，不能看到 VLESS 就自行添加 REALITY 设置。
- UUID：用于 VLESS 用户身份配置，不能拿其他协议的密码代替。
- 服务器名称：
servername与 TLS 握手有关，填错可能导致证书或握手错误。 - REALITY 参数：公钥、短 ID 等必须与服务端对应；节点名称相同不能证明参数一致。
- 传输方式：TCP、WebSocket、gRPC 等设置需要两端匹配，不能只改一个字段。
Hysteria2 与 TUIC 依赖 UDP 路径
Hysteria2 和 TUIC 使用基于 QUIC 的传输，连接服务器需要可用的 UDP 路径。若当前网络限制 UDP，普通 HTTPS 网页能打开，也不能说明这类节点一定能连接。此时应结合日志检查超时、认证和 TLS 错误，而不是反复修改规则模式。
Hysteria 第一代与 Hysteria2 也不能混用。订阅转换时若把第二代节点输出为第一代类型，或丢失必要认证参数，换一个策略组并不能修复。最稳妥的做法是选择订阅服务明确提供的 mihomo 兼容配置，并核对生成后的节点类型。
规则集：复用规则与控制匹配顺序
rule-providers 用于把一组规则作为独立资源维护，再用 RULE-SET 在主规则中引用。它并非 mihomo 首创；历史 Clash Premium 已有对应能力。mihomo 在这一体系上继续扩展格式与匹配能力，具体可用字段仍由所运行的内核版本决定。
先分清三种规则行为
domain：面向域名条目，不要把完整的DOMAIN-SUFFIX,example.org当作普通域名直接塞入。ipcidr：面向 IP 网段，例如192.168.0.0/16。classical：使用带规则类型的条目，例如DOMAIN-SUFFIX,example.org。
下面是一个本地规则集示例，不含代理节点。将第一段合入现有配置；路径按内核实际工作目录解析，并确保该目录下存在第二段所示文件。它演示的是引用关系，不是一份可以替代完整订阅的成品配置。
rule-providers:
local-direct:
type: file
behavior: classical
format: yaml
path: ./rules/local-direct.yaml
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,DIRECTrules/local-direct.yaml 的内容如下，两个条目分别匹配保留的示例域名与私有网段：
payload:
- DOMAIN-SUFFIX,example.org
- IP-CIDR,192.168.0.0/16,no-resolve实际迁移时应保留自己的最终策略，不能照抄示例里的 MATCH,DIRECT 后就期待流量经过代理。规则通常自上而下匹配，宽泛的直连规则放在前面，会让后面的代理规则没有机会命中。引用的策略组名称也必须真实存在，大小写和空格都要对应。
规则集格式不是随意互换的
mihomo 支持的 MRS 二进制规则格式有特定适用范围，主要用于 domain 和 ipcidr 行为，不能把任意 classical 文件改个扩展名就使用。远程规则集的 interval 以秒计，例如 86400 表示一天；这是规则资源的更新周期，并不等于客户端订阅 Profile 的刷新周期。
TUN 增强：扩大接管范围，也增加排障层次
系统代理主要影响主动遵循代理设置的应用；TUN 则通过虚拟网络接口与路由接管更多 IP 流量，适合处理不读取系统代理的程序。历史 Premium 也有 TUN，因此差异不应简化成“旧版没有、新版才有”。mihomo 的重点在于持续维护的 TUN 实现、网络栈选择，以及与路由、DNS 配合的配置能力。
栈、路由与 DNS 是三件事
| 配置项 | 主要作用 | 排查重点 |
|---|---|---|
tun.stack | 选择 system、gvisor 或 mixed 等受支持的处理方式 | 以当前内核和系统支持情况为准，不凭名称判断快慢 |
tun.auto-route | 自动配置流量进入 TUN 所需的路由 | 与现有 VPN、容器网络和自定义路由是否冲突 |
tun.auto-detect-interface | 自动识别出站接口 | 多网卡、网络切换时是否选对出口 |
tun.dns-hijack | 接管匹配条件的传统 DNS 请求 | 不能据此认为应用内 DoH 也已被自动接管 |
Linux 下创建 TUN 设备、修改路由需要相应权限。图形客户端可能通过已安装的特权服务完成这些操作，独立内核则需要自行处理权限与服务管理。遇到权限不足，应先核实服务状态、日志和 /dev/net/tun 是否可用，不要通过反复切换节点来排查设备创建失败。
下面仅展示常见的 TUN 配置片段，需合入已有 DNS、节点和规则配置后测试。它不包含完整的 DNS 监听配置，也不意味着所有设备都适合直接启用自动路由。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53配置兼容：能解析不等于行为一致
常见的 proxies、proxy-groups、rules 等结构仍然熟悉，但迁移不能只做一次文本复制。旧字段可能已改变推荐写法，新增字段也可能被旧内核拒绝或忽略；即使语法通过，DNS、策略组选择和进程匹配的结果仍需实际验证。
先验证文件，再启动接管
mihomo -v
mihomo -t -f ./config.yaml第二条命令用于配置检查，不是一次完整的网络连通性测试。通过后仍需确认节点握手、DNS 解析和分流结果。若使用图形客户端，注意它可能在启动前对订阅进行合并或覆写；手工检查的原始 YAML，与最终交给内核的运行配置可能不是同一份。
- 核对监听端口：例如计划使用
mixed-port: 7890，就确认浏览器或系统代理也指向本机 7890，而非旧配置中的其他端口。 - 核对控制接口：
external-controller与代理端口用途不同。若使用127.0.0.1:9090，9090 是管理接口，不是供浏览器上网的 HTTP 代理端口。 - 核对订阅内容：只有节点列表的订阅不一定包含策略组、DNS 和规则。客户端如何补齐这些内容，需要查看其配置合并机制。
- 核对本地覆写：自定义规则、端口和 DNS 应放入客户端提供的持久化覆写机制，直接修改远程订阅文件可能在刷新时被覆盖。
DNS 与进程规则单独验证
fake-ip 与 redir-host 是 DNS 处理模式，不是代理模式。切换内核时若同时改变 DNS 模式、上游服务器和 TUN 开关，就很难判断问题来自哪一层。建议先维持原来的 DNS 方案，确认基本连接后再逐项调整。
进程名、进程路径等规则还依赖系统支持、内核权限及连接信息能否正确获取。规则写得正确，也可能因为无法识别进程而不命中。排查时查看连接记录中的进程信息与命中规则；不要把所有未命中情况都归因于规则顺序。
迁移验证：一次只改变一个变量
迁移的目标是明确哪些能力得到补齐，以及现有配置是否保持预期行为。可以按下面的顺序验证；每一步都留下结果，再进入下一步，比一次性打开所有增强选项更容易定位问题。
- 备份：保存原 Profile、本地规则、覆写配置，以及当前使用的端口和 DNS 设置。订阅地址可能包含访问凭据，不要把完整内容贴到公开日志中。
- 基础代理：先关闭 TUN，用一个确认可用的节点测试本机 7890 代理入口，排除协议和认证错误。
- 规则验证：分别访问应直连与应代理的站点，检查连接记录中的命中规则及最终策略，而不只看网页是否打开。
- 规则集加载：检查 provider 的加载状态；文件路径错误、下载失败和条目格式错误是不同问题，应按日志分别处理。
- TUN 接管：最后启用 TUN，验证不遵循系统代理的应用，并检查局域网访问、其他 VPN 与网络切换。
- 订阅刷新：手动刷新一次，确认自定义设置仍在，再安排自动更新。
是否值得迁移，主要看实际需要：订阅包含 VLESS、Hysteria2 等节点，或需要更细的规则与持续维护的 TUN 功能，mihomo 的价值较明确；如果现有连接异常，仍应先区分节点故障、配置错误与系统网络冲突。更换内核能解决能力缺口，却不能代替对服务端参数和本地路由的检查。