修改最终策略前，先估清哪些请求会受影响：只有在更靠前规则都不成立（或因 UDP 被跳过）之后，才会用到 MATCH。官方定义 MATCH 为匹配所有请求、无需条件，示例置于 rules 末尾。因此改它的策略，影响面等于“当前列表的剩余集合”，而不是全部流量，除非上面几乎没有能成立的规则。
适用条件
适用于准备把末行 MATCH 的出站从例如 auto 改成 DIRECT、REJECT 或其它代理组，且暂不改动其上方规则的场合。若你其实要改的是某类域名或某国 IP，应改 DOMAIN-*、GEOSITE、GEOIP 等，评估对象就不是最终策略。评估必须基于现有从上到下的优先级：顶部规则优先，已命中的请求不会因为你改 MATCH 而换出站。
划定 MATCH 实际覆盖的请求集合
把 MATCH 上方每一类规则看成“已从剩余集合里拿走的流量”，剩下的才是受影响集合。
已被拿走的典型部分包括：完整域名、后缀、关键字、通配符、正则以及 GEOSITE 命中的域名（注意 DOMAIN-SUFFIX 的 google.com 不包含 content-google.com 这类仅中间拼接的名字）；IP-CIDR / IP-CIDR6、IP-SUFFIX、IP-ASN、GEOIP 在已有目标 IP 时拿走的地址（IP-CIDR6 只是别名）；DST-PORT、NETWORK、入站类、进程类、UID、DSCP 等按端口、协议、进程拿走的连接；RULE-SET、AND / OR / NOT、SUB-RULE 按集合或逻辑拿走的连接。
仍可能留在剩余集合里的，包括：未写入任何域名规则的站点；因匹配目标 IP 规则时未做 DNS 解析、且后面的 IP 规则带 no-resolve 又没有更早解析结果，因而没被 GEOIP 等收走的域名；来源 IP 才满足、但规则未加 src 的情况；逻辑规则括号不正确导致从未成立的那一批。把这些类别列出来，就是改最终策略时的影响面清单。
把 UDP 跳过算进影响面
文档指出：请求为 UDP 且节点没有 UDP 支持（例如 ss 未写 udp: true）时，会继续向下匹配。因此，即便某条域名规则的策略现在不是 MATCH，只要该策略对 UDP 不可用，这些 UDP 仍会进入最终策略。修改 MATCH 前，应单独列出“前方规则能匹配、但节点无 UDP、从而落入 MATCH”的请求，避免只按 TCP 估算。NETWORK,udp 若出现在 MATCH 上方且成立，会从剩余集合中再拿走 UDP，评估时要按它的位置计算，而不是默认 UDP 全归最终策略。
评估不足时的下一步
若无法判断某类请求是否已被上方规则拿走，选若干代表性连接，按类型与载荷逐行核对直到 MATCH，用核对结果修正影响面清单，再改策略名。不要在清单未完成时同时调整 MATCH 位置或插入新的宽泛规则，否则影响面会与评估脱节。若发现剩余集合过大或过小，应先增删上方有条件规则，待集合稳定后再改 MATCH 的策略。MATCH 不能加匹配条件，无法用它做精细分流；需要缩小影响面时，只能在它之前增加能成立的规则。