回归检查表用于在 rules 变更后，用同一组网址、预期匹配类型、预期出站做对照。官方没有现成模板，表必须按规则类型和从上到下的优先级来建，使每一行都能对应到可验证的匹配器。
适用条件
适用于规则列表会定期增删，且有一组必须保持分流稳定的主机名或 IP。每条记录至少包含：请求目标（完整域名或 IP）、协议 tcp 或 udp（对应 NETWORK）、预期命中的规则类型、该类型在文档中的匹配范围、预期出站、未命中时应落到的下一条（通常最终为 MATCH）。
判断依据：表中的预期规则类型必须是文档已有类型。完整主机用 DOMAIN；需要子域时用 DOMAIN-SUFFIX，并记住后缀 google.com 不匹配 content-google.com；集合用 GEOSITE 或 RULE-SET。类型与目标不一致的行不能进入表。
建立检查表的步骤
第一步，按业务列出常用网址，改写成内核会看到的主机名。每一行先问完整 DOMAIN 是否足够；足够则定为 DOMAIN，作为最窄的回归锚点。
第二步，为可能走后缀或集合的站点加对照行。同一主域增加 DOMAIN-SUFFIX 行：子域应命中，文档排除的那种前缀拼接不应命中。GEOSITE 行写明集合名与出站，并另选一个应属于该集合和一个不应属于该集合的域名。RULE-SET 同样要有正例和反例。
第三步，补非域名维度。依赖端口则增加 DST-PORT 行，例如 DST-PORT,80,DIRECT。依赖协议则增加 NETWORK 行。含进程则增加 PROCESS-NAME 或 PROCESS-PATH 行，并注明 Android 上进程名可匹配包名。这些行不要和域名行写成一句，否则失败时无法判断是哪一类变了。
第四步，IP 类单独建行：IP-CIDR、IP-CIDR6、IP-SUFFIX、IP-ASN、GEOIP。每行标注是否使用 no-resolve。同一域名要能对照两种情况：仅域名规则时的出站，以及允许解析后 IP 规则是否抢先。更早匹配若已触发解析，带 no-resolve 的目标 IP 规则仍可能命中，表中应有此前是否已解析一列。
第五步，逻辑规则与子规则各占行。AND、OR、NOT 写出括号内 payload 的真假组合，至少覆盖仅第一条真、仅第二条真、都真。SUB-RULE 行要写主条件以及子规则中预期的那一条。表末用 MATCH 兜底，对应以上均不应命中的网址，出站为该条指向的策略，例如 MATCH,auto。
第六步，每行标明在当前列表中的相对位置：该类型在某宽规则之上还是之下。位置列是顺序变化后能否保持结果的判断依据。
执行失败时下一步
某行实际出站不对：不要改表去迁就现状。按从上到下找到第一条满足该行目标的规则，对比预期类型。若实际命中更宽（关键字、正则、通配符、集合或 OR），把列表改回表所要求的窄类型，或更新表并注明有意扩大，二者只能选其一。
仅 udp 失败：查节点 udp 支持与 NETWORK 行。IP 行对不上：查 dns 是否被触发以及 no-resolve、src。通配符行失败：确认只用 * 与 ?。逻辑行失败：按表中真假组合拆开验证括号。
检查表应随规则变更增删行，但一次只引入与当次改动相关的新行，其余行保持不变。表本身不改变匹配精度，只把类型、顺序和 MATCH 终点变成可重复对照的记录。