结论先说:源站返回 200 不代表用户和爬虫拿到的就是 200。当死链在源站复测正常、却在部分地区或部分网络持续报错时,你要保留的不是“我复测过是好的”这句话,而是一组能区分源站、边缘节点、客户端三段链路的时间戳证据。缺少这组证据,后续无论找运维、CDN 服务商还是搜索引擎,都只能停留在互相复现不出来的扯皮阶段。
这两种情况的处理动作完全不同,判断依据是同一时刻不同位置的响应差异。
如果边缘节点缓存了一份旧的 404 或 410,那么源站修好之后,边缘仍会继续返回错误,直到缓存过期或被清除。典型证据是:源站直连返回 200,带缓存标记的请求返回 404,且响应头里出现较老的缓存时间或命中标记。此时处理动作是清除对应 URL 的边缘缓存,然后重新验证;如果清除后立即恢复,说明问题在缓存层,你要接着确认这批 URL 是否都走了同一条缓存规则。
如果边缘节点回源时拿到的是错误响应,那缓存清除不会解决问题。典型证据是:清除缓存后仍然 404,但源站直连始终 200。这时要检查回源请求是否被源站按不同 Host、不同协议或不同来源 IP 区别对待——例如源站对特定回源网段返回了拦截页或空响应。处理动作是抓一次回源请求的完整头信息,交给源站侧核对,而不是继续在边缘侧反复刷新。
证据的价值取决于时间是否对齐。以下四类记录应尽量在同一分钟窗口内采集,并统一使用 UTC 或同一时区标注。
这四类证据里,回源请求记录最容易被忽略,却往往是唯一能定位责任边界的一份。没有它,源站和边缘双方都可以声称自己没问题。
假设某 URL 在源站直连返回 200,在某个边缘节点持续返回 404。你先清除了该节点的缓存,再次请求仍为 404。此时不要重复清除,而应做两步:
第一步,从源站访问日志中找出边缘节点在清除缓存后发出的那次回源请求,确认它请求的 Host 和路径是否与预期一致。如果日志里根本没有这次回源记录,说明请求被边缘侧拦截或未真正回源;如果有记录且返回 404,说明源站对这次回源请求给出了错误响应,问题在源站侧的路由或规则。
第二步,根据第一步结果决定联系对象:没有回源记录就找边缘服务方,有回源记录且返回错误就查源站规则。这个动作的价值在于,它把“清缓存无效”这个模糊现象,转换成了一个能指向具体一方的判断。
如果错误只在特定客户端出现,而源站直连和边缘节点响应都正常,那问题更可能在客户端侧——例如本地 DNS 缓存、代理设置或浏览器缓存。此时保留源站和边缘证据仍然有用,但处理重点应转向客户端环境复现。
如果错误 URL 数量很大且集中在某个目录,优先怀疑批量规则或重写规则,而不是逐个 URL 排查。此时应保留一条规则生效前后的对比记录,而不是几十条单 URL 的响应截图。
另外要注意,robots.txt 的抓取限制不等于可靠的索引移除,边缘异常期间如果顺手改了 robots.txt,后续判断会被这条改动干扰,所以修改前应先固定当时的 robots.txt 内容作为证据。同理,站点地图不保证收录,不要用“已提交站点地图”替代对具体 URL 响应状态的核查。
把上述四类记录按 URL 和时间整理成一份可复查的清单,每条记录至少包含:采集时间、采集位置、请求 URL、返回码、关键响应头、以及采集方式。采集方式要写清楚是直连源站、经边缘请求还是第三方探测,否则后续无法判断证据的适用范围。
完成这份清单后,再决定是清除缓存、调整回源规则还是提交反馈。清单本身不解决问题,但它决定了你下一步的动作是否建立在可验证的事实上,而不是建立在“我这边看是好的”这种无法对齐的判断上。缺少时间对齐和回源记录的证据,任何一方都可以合理否认问题存在,处理就会一直停在原地。