规则模式下，Mihomo 从上往下匹配请求。前面已经匹配成功，后面的规则就不会替你重新作出选择。因此一条规则写得正确，却始终没有命中，常常是因为更早的位置已经接走了请求。
用一个小例子看顺序
rules:
- DOMAIN,docs.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,REJECT
- MATCH,DIRECT这里 docs.example.com 会先匹配第一条，而 api.example.com 会匹配第二条。把前两行对调，docs.example.com 也会先被后缀规则匹配。示例只用于解释顺序，example.com 是示意域名，不是网络测试目标。
特例通常放在宽泛规则之前
某个子域需要单独处理时，先放明确的特例，再放覆盖更大范围的规则或规则集。MATCH 作为兜底放在末尾；如果提前放置，后面的规则往往再也没有机会参与匹配。
规则数量并不能代表质量。一份规模较大的规则集可能覆盖更多情况，也可能让你难以解释某次命中。添加之前应知道它处理什么请求、交给哪个策略，以及与个人特例的先后关系。
用实际请求验收
修改后重新发起目标请求，在连接页查看命中项和最终出口。旧长连接可能继续保留原来的路径，必要时关闭对应连接再测试。目标网页还可能调用多个域名，应分别观察失败的那个请求。
最后检查客户端覆写是否改变了规则插入位置。有的修改是前置，有的追加到末尾。你在编辑器里看到的规则如果没有进入最终生效配置，再正确的顺序也不会起作用。确认生成结果，比反复切换节点更适合处理命中问题。