维护流媒体相关访问的排查记录，核心是把「规则如何匹配」写成可复查的过程，而不是把某个出站名称写成平台已解锁。官方路由规则按从上到下的顺序匹配，列表顶部的规则优先级高于其底下的规则。记录只应回答：这条请求被哪一类条件截获、是否继续向下匹配、最终策略名是什么。策略名只是配置里的标签，不能写成播放保证或检测绕过。
适用条件与不可逾越的边界
适用条件包括：配置中已存在 rules 列表；排查对象是域名、IP、端口、进程或逻辑组合能否被规则命中；需要把广告主机、内容站点、局域网或保留地址、以及兜底策略分开登记。不适用的情况是：用命中结果承诺某流媒体可以观看、画质可用，或把代理组名称当作解锁凭证。
判断依据必须绑定规则类型本身。DOMAIN 只匹配完整域名。DOMAIN-SUFFIX 匹配后缀：以 google.com 为例，可匹配 www.google.com、mail.google.com 和 google.com，但不匹配 content-google.com。DOMAIN-KEYWORD 是关键字匹配。DOMAIN-WILDCARD 仅支持 * 与 ?，且与配置文件其他位置的通配符并不相同。DOMAIN-REGEX 按正则匹配域名。GEOSITE 只表示命中 Geosite 数据集中的域名分类。以上信息足以支撑「命中了哪条分类」，不足以支撑「已解锁」。
若请求为 udp，而代理节点没有 udp 支持，则会继续向下匹配。这一条必须写入记录：失败可能是「UDP 条件下落」，不是「站点策略已经无效」。
按规则类型建立可复查清单
- 先把流媒体相关候选写成三类：完整主机名用
DOMAIN，公共后缀用DOMAIN-SUFFIX，一批分类用GEOSITE。每一行记录三个字段：规则类型、payload、出站名。出站可以是REJECT、DIRECT或某个代理组名，记录里不得附加效果描述。 - 把确定要丢弃的广告主机放在更靠上的位置，例如
DOMAIN,ad.com,REJECT，避免被后面的宽泛后缀或关键字截获。判断依据就是优先级：顶部先匹配。 - 对只想按地址段处理的目标使用
IP-CIDR、IP-CIDR6、IP-SUFFIX、IP-ASN或GEOIP。域名开始匹配关于目标 IP 的规则时，会触发 dns 解析以检查目标 IP 是否匹配；可选择no-resolve以跳过解析。若更早的匹配已经触发过解析，带no-resolve的目标 IP 规则仍可能被命中。记录中要写明是否跳过解析、解析是否已被更早规则触发。 - 若访问来自固定客户端，用
PROCESS-NAME、PROCESS-PATH或其通配符、正则形式收窄范围。Android 上进程名可以匹配包名。这样记录的是进程，不是平台权限。 - 需要同时满足多个条件时使用
AND、OR、NOT，并注意括号。需要进入另一批规则时用SUB-RULE。清单末尾用MATCH承接所有未命中请求。MATCH无需条件、匹配所有请求，因此命中MATCH只能记为未分类，不能记为成功。 - 每次只改一类变量：顺序、payload 或出站名，并记下变更前后命中的规则。逻辑规则括号错误时，先对照
AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT这种官方写法核对，而不是改出站来拼凑结论。
失败时沿优先级继续核对
当页面不能打开或客户端报错时，下一步仍是核对匹配过程，而不是补充保证语句。若怀疑被宽泛规则截获，检查是否存在写在精确 DOMAIN 之前的 DOMAIN-KEYWORD 或过大的 DOMAIN-SUFFIX。若怀疑 IP 类规则误伤，检查是否缺少 no-resolve、解析结果是否落入 GEOIP 或 IP-ASN。若怀疑根本不是同一条流，再用 IN-TYPE、IN-PORT、DST-PORT、SRC-PORT、NETWORK 核对入站与端口。若使用规则集合，确认 RULE-SET 引用的名称与已配置的集合一致。
仍无法定位时，把该次请求明确记为落入 MATCH，并停止把单次失败推广为全部流媒体站点的结论。合格的排查记录应让他人只看规则类型与顺序就能复述命中原因，且看不到任何解锁承诺。