验证要回答的问题和成立标准
用重叠规则验证先后关系，目的只有一个：证明最终策略跟随“第一条为真的规则”，而不是跟随类型名称或后写条目。官方依据是：规则将按照从上到下的顺序匹配，列表顶部的规则优先级高于其底下的规则。适用条件是你能稳定访问同一目标，并且按手册语义，至少两条规则对该请求同时为真（包含关系或交叉关系）。完全互斥的两条规则不适合做先后验证，对调它们不会产生可解释的变化。
判断依据建议三条同时成立。第一，位置在上的那条，其出站成为结果。第二，只交换这两条的上下位置、不改 payload，结果变成另一条的出站。第三，删掉更宽的那条后，更窄的那条可以单独命中，说明它本身写对了，先前只是没有轮到。样例末尾保留 MATCH：它匹配所有请求、无需条件，用来观察“两条重叠规则都不成立”时的兜底，也能用来验证中途插入 MATCH 会截断下方规则。
按官方语义准备重叠最小样例
每次只放最少规则，每次只改一处顺序，并固定同一主机名与同一传输层。第一组用域名包含关系。DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配后缀，手册写明 google.com 匹配 www.google.com、mail.google.com 和 google.com，但不匹配 content-google.com。因此对 www.google.com，可同时写 DOMAIN-SUFFIX,google.com 与 DOMAIN-KEYWORD,google，两者都应为真。把后缀放在关键字之上与之下各请求一次，最终策略应分别等于这两条上的出站名。不要用 content-google.com 去验证后缀与关键字的重叠，因为按定义后缀规则本就不应命中。DOMAIN-WILDCARD 仅支持 * 和 ?，且与配置其他处 Clash 格式通配符不相同，验证时不要混用其他通配写法。GEOSITE 与后缀若覆盖同一批域名，同样只改顺序、不改集合名。
第二组用逻辑规则。手册示例有 AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT、OR,((NETWORK,UDP),(DOMAIN,baidu.com)),REJECT、NOT,((DOMAIN,baidu.com)),PROXY。对 baidu.com 的 UDP，AND 与单独域名规则可能同时为真；对非 baidu 的 UDP，OR 与 NETWORK,udp 可能同时为真。验证时括号结构保持不变，只移动整条逻辑规则相对其他规则的位置。括号漏写时真值会与预期不符，那种结果变化不能记成先后关系，应先改括号再比顺序。
第三组用目标 IP 与 no-resolve。IP-CIDR 和 IP-CIDR6 效果一样；域名开始匹配目标 IP 规则时会触发 dns 解析；可以选择 no-resolve 跳过解析。但如在更早的匹配中触发了 dns 解析，则依旧会匹配到添加了 no-resolve 选项的目标 IP 类规则。因此验证 GEOIP 与更具体 IP-CIDR 的先后时，不能只看后一条是否写了 no-resolve，还要看上方是否已有会触发解析的目标 IP 规则。RULE-SET 视为插在引用行的一组规则，验证的是该引用行相对其他行的优先级。
第四组把 MATCH 插到两条重叠规则中间：上方那条仍应按自身 payload 命中，下方那条应轮不到。这是检查截断最直的样例。若请求为 udp 且节点没有 udp 支持（例如 ss 节点没写 udp: true），匹配会继续向下，样例里不要把“无 UDP 能力的出站”当成成功命中，否则先后关系会被继续扫描干扰。
对调后没有变化时怎么处理
对调理应重叠的两条规则后策略不变，按这次序缩小问题。先确认目标是否落在手册定义的范围内，例如用不能被后缀匹配的主机名做样例，对调本来就没有意义。再确认没有第三条更靠上的宽规则或 RULE-SET 已经截获。接着检查逻辑规则括号、通配符类型是否误用。然后检查是否因更早目标 IP 规则触发了 dns，使带 no-resolve 的规则仍然成立，造成“文本上看不该重叠、求值时重叠”。若仅 UDP 样例失败，改为核对 NETWORK 与节点 UDP 能力。验证只用于定位先后，不用于推断出站快慢；确认后把更具体规则保持在更宽规则之上，并将 MATCH 留在列表最末。