规则分流不符合预期，如何检查实际出口？

规则分流不符合预期时，应先查看目标连接是否进入内核、命中了哪条规则，以及最终选择了什么出口。只看配置文件里“写过一条规则”并不够，因为规则顺序、代理组选择和实际请求的域名都可能让结果与想象不同。

先确认请求进入了哪里

打开出现异常的应用，发起一次明确请求，再查看客户端提供的连接记录。如果没有对应记录，先检查应用的代理设置或接管方式。尚未进入内核的请求，不会因为在配置末尾增加规则而自动被接管，这一步可以避免大量无效修改。

同时确认当前启用的配置文件。有时修改的是本地副本，正在运行的却是另一份远程配置。先对照配置名称与更新时间，再确认内核实际加载成功；解析错误被忽略时，也可能一直使用此前仍然有效的设置。

看清顺序与匹配范围

在 mihomo 的规则机制中，规则按从上到下的顺序匹配，靠前的规则有更高优先级。完整域名规则、后缀规则和关键词规则的范围不同，不能只看几个相似文字就认为含义相同。调整之前先明确你要覆盖的是一个主机，还是整个域名范围。

如果目标先命中了前面的宽泛规则，后面更具体的规则未必有机会生效。应结合连接记录识别实际命中项，再做最小范围调整。不要一上来删除所有规则，或增加一个包揽全部连接的条件来掩盖问题。

代理组不是最终节点

规则可能指向代理组，而代理组又会选择其中的出口。看到“已经走代理”时，仍需查看组内实际节点是否符合预期。自动选择策略还可能在不同测试间切换出口，排查时应记录实际结果，必要时使用明确选择的出口做有限对照。

例如，目标命中了正确的工作分组，但分组当前选择了另一个地区的节点，问题在组内选择而非域名规则。相反，如果分组和节点都正确，却一直无法访问，就应继续检查节点或目标服务，不要反复移动规则顺序。

一个网页可能有多个请求

页面主域名、图片、登录和接口可能来自不同地址。首页显示正常却无法登录时，应检查失败操作对应的请求，而不是仅检查首页。记录必要的域名和错误类别，不要把包含登录令牌的完整请求地址复制到公开场合。

1. 备份当前配置，记录异常任务和实际命中结果。
2. 只改与失败请求直接相关的一条规则或一个选择。
3. 重新建立请求，确认命中与任务结果是否改变。
4. 检查原本正常的本地与普通访问，确认没有引入副作用。

把修正放在能持续生效的位置

远程配置更新可能覆盖直接写入的内容。需要长期保留的修改，应采用具体客户端支持的覆写或独立规则管理方式，并注明原因。每次更新后用原任务复核，不要因为某次修复成功就永久忘记它。

常见误区是把“全局能用”直接当作规则一定错误的证明。切换过程也可能改变出口或重新建立连接，应核对这些条件后再下结论。一次只改一项，保留前后记录，才能让修正建立在可复查的证据上。

继续阅读：DNS、出口 IP 与地区识别的关系；连接成功却只有一个网站打不开，怎么排查？