为单站追加一条路由规则之后，需要检查的副作用是：该站请求的出站变了，同时其他域名、同一站点的其他协议、或无关进程的连接也被这条规则提前截走。适用条件是当前配置已经包含 rules 列表、请求已经进入内核，并且你这次只针对某一个站点增加或修改了规则。判断是否属于“单站改动”时，以文档中的匹配定义为准，而不是以站点中文名或业务名称为准。若规则类型本身就会覆盖后缀、关键字或整个进程，则它从一开始就不是单站规则，检查重点应放在收窄，而不是继续叠加。
按自上而下的优先级模拟命中
规则将按照从上到下的顺序匹配，列表顶部的规则优先级高于其底下的规则。判断依据是：一旦命中就结束，后面的 GEOSITE、GEOIP 或 MATCH 不会再处理该请求。具体步骤：第一，记录新增规则的位置、匹配字段和出站名称。第二，列出该站可能出现的完整主机名，区分是否只有根域、是否还有其他主机。第三，从列表顶部逐条查看，是否存在比新规则更宽、且会先命中的条目。第四，如果请求是 UDP，而所选代理节点没有 UDP 支持，则会继续向下匹配，从而出现 TCP 已走新规则、UDP 仍走旧规则的分裂。失败时下一步：把新规则移动到真正需要它优先的位置，避免放在过宽规则之下被架空，也不要放在列表最顶部误伤其他站点；对 UDP 再单独核对，不要只根据页面能否打开下结论。
对照匹配类型防止覆盖面过大
DOMAIN 匹配完整域名。DOMAIN-SUFFIX 匹配域名后缀，文档中的例子是 google.com 会匹配 www.google.com、mail.google.com 和 google.com，但不匹配 content-google.com。DOMAIN-KEYWORD 为关键字匹配，容易带上含同一片段的无关域名。DOMAIN-WILDCARD 仅支持 * 和 ?，这里的通配符与配置文件其他地方的 Clash 格式通配符不相同。DOMAIN-REGEX 按正则匹配。GEOSITE 匹配数据集内的域名，范围由数据决定。判断依据：把实际主机名代入上述定义，所有会被写中的名字都会使用同一出站。操作上，只需要一个精确主机名时使用 DOMAIN；确实需要子域时才用 DOMAIN-SUFFIX，并确认该后缀不会覆盖其他业务。逻辑规则 AND、OR、NOT 以及 SUB-RULE 都需要注意括号，例如用 AND 把域名和 NETWORK 组合，才能把影响限制在某一协议。失败时下一步：将关键字、正则或地理站点规则改成更窄的域名规则，并确认列表末尾的 MATCH 仍能匹配其余请求。
排查 DNS 解析、附加参数和进程条件
IP-CIDR、IP-CIDR6、IP-SUFFIX、IP-ASN、GEOIP 等属于目标 IP 类规则。域名开始匹配这些规则时，mihomo 将触发 DNS 解析以检查目标 IP 是否匹配；可以选择 no-resolve 以跳过解析。如果在更早的匹配中已经触发了 DNS 解析，则依旧会匹配到添加了 no-resolve 的目标 IP 类规则。附加参数 src 会将目标 IP 匹配转为来源 IP 匹配。PROCESS-PATH、PROCESS-NAME 以及对应的通配符、正则用于匹配进程，在 Android 平台上进程名还可以匹配包名，其作用范围是该进程的连接，而不是某一个站点。判断依据：单站修改之后如果出现额外解析，或无关目的地、无关进程一起改道，即存在副作用。步骤：单站场景优先只保留域名类规则；必须使用 IP 规则时，检查其上方是否已经触发解析，并明确是否添加 no-resolve；不要用进程规则代替站点规则。失败时下一步：暂时移除同组的 IP 规则与进程规则后重新加载配置，观察是否只剩下预期域名被命中。