写好一条规则后，应用仍然走原来的网络路径，第一反应常常是把规则挪到最上面。但如果请求没有进入Mihomo，任何规则都不会让它自动被接管。排查应先找入站证据，再看目标信息和顺序，最后验证实际出口与连接结果。

没有入站，规则就没有处理对象

System Proxy依赖应用遵循系统代理设置，部分应用可能自行连接、使用独立代理或具有例外。TUN依赖虚拟接口和系统路由覆盖目标流量。两者都不能只凭设置界面上的状态判断请求路径。先发起一个可识别的测试请求，查看核心连接记录有没有对应目标。

没有记录时，结合TUN与系统代理的接管差异检查应用配置、接口和路由；已经有记录时，再看核心实际接收到的是域名还是IP、TCP还是UDP。不同入站携带的信息可能不同，不要拿浏览器显示的名称直接代替规则匹配时可用的目标信息。

确认核心加载了哪份配置

文件已保存不等于配置已加载。客户端可能维护自己的活动配置、生成运行文件或在重载时遇到错误。先确认运行中的核心、配置来源、模式与重载结果，再核对规则条目。规则模式下，rules 通常按从上到下的顺序匹配，更靠前的条件可能先接住请求。

DOMAIN 匹配完整域名，IP-CIDR 关注地址范围，RULE-SET 引用规则集合，MATCH 无条件匹配。规则集合还需要对应provider有效加载；条目存在并不证明引用的数据可用。可对照流量路由说明查看不同规则的判断对象。

域名和IP是两类匹配线索

当目标IP规则需要地址信息时，核心可能触发DNS解析。no-resolve 让目标IP规则不为此次匹配主动触发解析，它不是全局禁用DNS，也不会阻止其他阶段已经发生的解析。如果先前匹配已取得目标IP，带有no-resolve的目标IP规则仍可能使用该信息匹配。

局部规则示例 · 仅说明匹配对象与顺序
rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

示例中的域名与地址范围用于说明语法，不代表实际服务或你的本地子网。将私有地址写入规则也不等于完成系统路由排除；两者发生在不同层。网络环境使用的网段应从本机和路由器的实际信息中确认。

从命中结果继续追到真实出口

命中规则后还要查看对应策略是否可用，代理组当前实际选择什么，以及协议能力是否支持这次连接。规则命中只说明决策完成，远端拒绝、超时、TLS错误或出口不可达仍然可能发生。不要为解决远端服务故障反复改写已验证正确的域名规则。

局域网请求还需要区分私有地址访问和服务自动发现。若IP直连与名称发现表现不同，按局域网路由与mDNS检查核对设备网络，避免把组播发现问题归到公网路由规则。

用一个请求做可恢复的对照

选择一个稳定、允许访问的目标，保留修改前配置，记录请求时间、入站类型、命中条目、所选策略和最终错误。一次只调整一个条件，重载后重新发起连接。已有连接可能继续沿用旧的决策；用新请求验证，才更容易区分规则变化与长连接缓存带来的差异。