一份规则配置不仅是一张网站清单，它还表达了匹配顺序、条件和动作。同一个请求可能符合多条描述，但最终按哪些条件作出决定，要看所使用的内核。先读懂这层结构，再添加规则，才能解释修改为什么有效或为什么没有生效。
一条规则至少要看条件与去向
条件描述要匹配什么，例如完整域名、域名后缀、IP 范围或进程；去向描述满足条件后交给哪个策略。策略可以直接决定连接方式，也可以把请求交给一个会继续选择节点的组。
例如，规则指向“资料阅读”组，而组内选择了某个节点。此时改变组内选择会改变后续连接的节点，但规则本身没有变化。排查时同时记下命中规则与实际去向，才不会把两个层次混在一起。
顺序会影响哪些规则得到机会
以 mihomo 常见规则列表为例，规则按从上到下的顺序进行匹配，靠前的规则优先。具体协议支持、逻辑规则和其他机制还会影响处理，不能把这一概括当成所有内核都完全相同的执行规范。
如果前面的宽泛条件已经决定了去向，放在后面的精确例外就可能得不到机会。安排规则时先写清哪些例外需要优先处理，再放较广的分类。不要只根据添加时间把每条新规则堆在末尾。
精确域名与后缀规则的范围不同
完整域名通常用于匹配某一个明确名称；后缀规则则覆盖该域及相应子域。关键字或正则的范围可能更宽，也更容易误匹配。名称里出现一段相似文本，不代表两个域名属于同一服务。
需要单独处理一个功能时，先找出实际请求使用的域名，再选择足够窄的规则。将整个上级域名改道可能连带影响登录、图片或其他业务；范围扩大前，应说明希望涵盖哪些请求。
规则集合仍然需要放在正确位置
规则集合把一组条件交给外部文件维护，但引用它的规则仍属于总的匹配流程。集合很长或更新很频繁，不代表它的优先级自动更高，也不代表你自己的例外一定会覆盖它。
检查时应同时确认集合是否加载成功、内容类型是否适配、引用位置是否正确。只看到下载成功，不能确认其中某条条件已被当前请求使用。订阅的节点集合与规则集合也需要分清。
兜底策略处理尚未被决定的请求
兜底规则用于给剩余请求安排去向。它的位置和目标都应明确，避免无意中把本来要精确处理的流量提前吸收。兜底并不说明请求安全、适合某个节点或能够完成业务。
在修改之前，可以用自然语言写出完整顺序：先处理哪些特殊请求，再按哪些类别分组，最后怎样处理其他流量。若这段说明无法自洽，往往应先整理意图，再改配置。
验证规则时同时看命中与连接
准备一个预期命中的请求和一个相似但不应命中的请求，保存配置后分别检查连接记录。这样既确认例外生效，也能发现条件是否过宽。不要只凭一个成功网页判断全部分流正确。
更新或切换策略后，已有连接可能继续保持原状态，验证时应关注新建立的请求。若需要进一步定位，可以沿着命中规则、策略组、节点和实际出口逐层核对，并保留原配置作为恢复点。