只看首页能否打开，会漏掉脚本、图片、接口等后续请求。官方路由规则对每一次请求单独、自上而下匹配，并没有“首页成功即整页成功”的判定。要把失败资源记下来，实质是把这些独立请求的域名、IP、端口和网络类型对应到具体规则类型，而不是只核对首页主机名是否出现在列表中。
适用条件
适用于页面主请求似乎成功、但部分资源失败，或需要把失败主机名从“整站”中分离出来的场景。可依据的类型包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、DOMAIN-WILDCARD、DOMAIN-REGEX、GEOSITE、IP-CIDR、GEOIP、DST-PORT、NETWORK、逻辑规则、RULE-SET 与 MATCH。规则页未记载额外的采集界面，因此记录方式建立在逐条规则匹配上。
把失败资源写成独立的域名或 IP 条目
首页文档只对应一次 DOMAIN 或 DOMAIN-SUFFIX 匹配。资源请求使用不同主机名时，必须各自走完整匹配过程。操作上，从失败资源的目标主机名出发，先用 DOMAIN 做完整匹配；再用 DOMAIN-SUFFIX 看是否与主站共享后缀。文档示例说明，google.com 作为后缀可匹配 www.google.com、mail.google.com 和 google.com，但不匹配 content-google.com。若失败资源属于名称相近、后缀不同，记录时应写下完整主机名，避免只记主站后缀。DOMAIN-KEYWORD 过宽会把未失败的资源算进去，不适合作为失败清单的唯一依据。DOMAIN-WILDCARD 仅支持 * 与 ?，与其他位置的 Clash 格式通配符不相同。GEOSITE 只能说明该资源是否属于某集合，集合未收录时不要当成已经记录。
把每条失败资源写成独立的 DOMAIN,主机名,策略 临时行并放在列表顶部，符合官方“顶部优先”的模型，也最接近逐条记录：不会被下方更宽的规则淹没。若某资源只有 IP、没有稳定主机名，则改用 IP-CIDR、IP-CIDR6 或 IP-SUFFIX 记录网段。匹配目标 IP 时会触发 DNS 解析；no-resolve 可跳过解析，但更早规则已经触发解析时，仍会命中带该选项的目标 IP 类规则。记录时要注明是按域名还是按解析后 IP 归类，否则同一资源会出现两条看似矛盾的结果。
记录端口、协议与落入 MATCH 的请求
DST-PORT 匹配目标端口，NETWORK 匹配 tcp 或者 udp。首页多为某一端口上的 TCP，失败资源却可能是其他端口或 UDP。文档写明：请求为 udp 且代理节点没有 udp 支持（例如 ss 节点没写 udp: true）时，会继续向下匹配。只记录首页结果，会得到“规则已指向某一出站”的不完整结论，实际 UDP 资源可能已落到后续规则。逻辑规则可把域名与网络类型组合，例如 AND,((DOMAIN,baidu.com),(NETWORK,UDP)),DIRECT，用于单独标记该域名的 UDP 资源，并需要注意括号。MATCH 无需条件、匹配所有剩余请求，未单独列出的失败资源最终都会落到这里，记录中应标明“未命中前述规则、落入 MATCH”。
进程与入站信息用于区分同一资源、不同客户端：PROCESS-NAME、PROCESS-PATH 及通配符或正则在 Android 上可以匹配包名；IN-TYPE、IN-PORT、IN-NAME、IN-USER 区分入站。它们不能代替资源主机名，但可避免把首页某一进程的成功写成整机成功。RULE-SET 引用的集合内部条目也要纳入记录来源，否则主 rules 列表看起来没有该域名。SUB-RULE 匹配至子规则时同样要注意括号。
失败时下一步
若已为失败资源写出顶部 DOMAIN 仍无法区分出站，应检查是否被 GEOIP、IP-ASN、REJECT 或 RULE-SET 改写，以及 no-resolve 是否让判断跳过了实际已经发生的解析。不要用更宽的 DOMAIN-KEYWORD 代替完整主机名清单，以免把正常资源记成失败。逻辑规则括号错误时记录会不准，应先拆成单条 DOMAIN 再组合。当规则侧已经能指出该资源命中的类型与出站、加载仍然失败，应停止在首页域名上反复添加后缀，改为核对该资源的 NETWORK、DST-PORT，以及 MATCH 之前是否存在更具体的 IP 规则。