先给结论:源站正常、边缘节点异常时,最该保留的不是“死链数量”,而是能证明同一 URL 在不同节点返回不同状态的那组对照证据。具体包括同一时刻的完整响应头、节点标识、请求路径、返回码与响应体摘要,以及源站直连的对照结果。只有这些证据能同时说明两件事:源站确实正常,异常确实发生在边缘层。缺少任何一半,后续排查都会退回到猜测。
假设某站点做站长死链查询时,抽查五个 URL 显示 404,但运维在源站服务器上直接请求同一路径却返回 200。此时如果只记录“五个 URL 是死链”,就无法判断问题出在边缘缓存、回源配置还是 URL 规范化。反过来,如果只记录“源站返回 200”,也无法说明边缘节点为什么给出 404。真正有用的是把两侧结果放在同一张对照记录里。
这个情境的关键边界是:个别样本成立不代表规模化后仍成立。抽查五个 URL 全部异常,可能只是命中了某个特定边缘节点或某条缓存规则;当样本扩大到几百个 URL 时,异常比例可能骤降,也可能因为缓存键设计问题而升高。因此证据要能支撑“扩大样本后如何验证”,而不只是解释当前这几个 URL。
边缘异常最直接的证据是完整响应头。重点记录返回码、缓存命中状态字段、回源相关字段、内容类型,以及任何能标识处理节点的字段。不同 CDN 或反向代理的头字段命名不同,不要预设某个字段一定存在,而应把实际收到的头原样保存。如果响应头里出现缓存命中标记,同时返回码是 404,这条记录的价值远高于单纯的“404”三个字。
很多边缘 404 并非资源消失,而是 URL 在边缘被改写。保留原始请求 URL、实际发出的请求 URL、是否带尾斜杠、大小写是否被转换、查询参数是否被保留。做法上可以同时请求带斜杠和不带斜杠两个版本,分别记录返回码。如果两者结果不同,说明边缘的规范化规则参与了异常,而不是源站缺少资源。
源站对照必须绕开边缘层,直接请求源站地址,并记录同样的字段。这一步的作用是排除源站自身问题。若源站直连返回 200 且响应体正常,而边缘返回 404,才能把问题定位到边缘。若源站直连也异常,则应先处理源站,边缘证据暂时搁置。
边缘缓存和节点状态会随时间变化,没有时间戳的对照记录无法复现。记录每次请求的绝对时间、发起位置或网络出口的大致范围,以及请求所使用的协议版本。同一 URL 在不同时间点结果不同,本身就是重要线索,说明可能存在缓存过期、节点轮换或配置发布。
拿到对照证据后,下一步不是立刻改配置,而是先判断异常是否可复现。可复现时,用同一组 URL 在多个节点重复请求,观察异常是否跟随节点移动。若异常只出现在固定节点,优先怀疑该节点缓存或配置;若异常跟随 URL,优先怀疑回源路径或 URL 规范化规则。
不可复现时,保留的时间戳和响应头就变成唯一线索。此时应扩大样本,而不是反复请求同一个 URL。扩大样本时保持请求方式一致,只改变 URL 集合,观察异常比例是否随 URL 特征变化。这一步的结果决定后续是继续在边缘层排查,还是回到源站检查内容发布流程。
还有一个容易忽略的边界:不同搜索引擎和不同抓取工具对边缘响应的处理方式可能不同。同一 URL 在某个工具里显示异常,在另一个工具里可能正常。因此对照记录里应写明请求工具和请求方式,避免把工具差异误判为边缘故障。若异常只在一个工具中出现,应先用独立请求方式复核,再决定是否继续排查边缘。
假设对 20 个 URL 做查询,其中 3 个返回 404。记录显示这 3 个 URL 都带查询参数,且响应头中有缓存命中标记;源站直连同样带参数返回 200。此时合理推断是边缘缓存键忽略了查询参数,导致不同参数命中同一份缓存。下一步动作应是检查缓存键规则,而不是删除这些 URL 或提交死链报告。
如果记录显示这 3 个 URL 不带参数、源站直连也返回 404,则问题在源站内容层,边缘证据不再关键。两种情况的区别完全来自对照记录,而不是来自死链查询工具给出的数量。这就是为什么源站正常而边缘异常时,证据的完整性比结论本身更重要。
最后提醒一点:请求量、抓取量或某项统计归零,不能单独证明处理正确。归零可能来自抓取限制、统计口径变化、工具配置调整或真实故障,需要结合响应头和时间戳一起判断。保留证据的目的,是让每一步判断都有可复查的依据,而不是用单一数字下结论。