📍 WDQWDWQD987AAAAA:216.73.216.245
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bea28e621115.html
📄

死链接检测工具，异常恢复后怎样区分缓存过期与真正修复

先看一个关键区别：缓存过期只改变你这次请求看到的响应，真正修复改变的是源站对同一URL的稳定输出。判断时不要只凭一次复检结果，而要用带时间标记的两次请求、响应头和源站日志交叉验证；如果只有CDN或代理层返回200而源站仍返回404，那属于缓存过期，不是修复。

条件一：复检结果从404变成200，但响应头仍带缓存标记

这是最常见的一类假象。CDN、反向代理或页面缓存插件会把上一次抓取到的404或410结果缓存一段时间，到期后重新回源，于是检测工具再次请求时拿到了200。此时真正变化的是缓存生命周期，不是链接指向的内容。

可区分的证据有三组：

• Age、X-Cache、CF-Cache-Status一类响应头是否显示命中；命中且Age较大，说明你看到的是旧副本。
• 同一URL连续两次请求，第二次是否仍返回200且内容长度一致；只出现一次200、随后又回到404，说明源站并未稳定输出。
• 源站访问日志中，复检时间点是否出现真实回源请求；没有回源记录，基本可判定为边缘缓存直接应答。

实际动作：在检测工具里对同一URL发起两次间隔请求，并记录每次的状态码、响应头和响应体摘要。如果第一次200、第二次404，下一步不是继续复检，而是要求清理该URL的缓存后再测；清理后仍为404，才回到修复流程。

条件二：源站已改，但检测工具仍报错

另一种情况恰好相反：源站确实把链接改对了，检测工具却持续报404或超时。这通常不是缓存过期，而是检测侧的问题——工具自身缓存、抓取节点未同步、请求头被源站拒绝，或者你检测的是旧URL而修复发生在新URL上。

区分依据：

• 用不带缓存的请求头（如Cache-Control: no-cache）直接请求源站，看状态码是否与工具一致。
• 核对检测报告里的URL与源站实际修改的URL是否完全一致，包括结尾斜杠、大小写和查询参数。
• 换一个抓取节点或稍后重试，若结果翻转，说明是检测侧同步延迟。

实际动作：把工具报告中的URL逐条与源站配置比对，确认修改落在同一路径上。若源站直接请求返回200而工具仍报错，下一步应调整检测工具的抓取设置或等待节点同步，而不是回退源站修改；盲目回退会把已经修好的链接重新改坏。

用响应头与源站日志建立判定顺序

把两类证据排成固定顺序，能减少反复。先看响应头是否指示缓存命中，再看源站日志是否有对应回源记录，最后才看状态码本身。原因在于状态码是最终呈现，缓存和代理都可能改写它；响应头和日志才是判断“谁在回答”的依据。

假设一个例子：某URL在检测工具中显示200，但Age为86400，源站日志在该时间点没有请求记录。按上述顺序，应先判定为缓存副本，清理缓存后复测。若清理后源站日志出现请求且返回404，则说明修复并未生效，需要回到内容或跳转配置处理。这个顺序不依赖具体工具，任何能查看响应头和日志的环境都适用。

哪些情况不该用缓存与修复二分法

有些异常既不是缓存过期也不是修复完成：robots.txt 的抓取限制会阻止检测工具访问，返回的可能是拒绝而非真实状态；站点地图里的URL返回200也不代表已被索引；HTTPS 只说明传输加密，不保证链接内容正确。这些情况下，先确认限制来源，再决定是否清理缓存或继续修复。

例外还包括：源站返回410而非404时，表示资源被有意移除，此时“修复”可能意味着更新引用页面而不是恢复原URL；重定向链过长导致工具超时，需要先缩短跳转再判断最终状态。把这些情况单独归类，能避免把非缓存问题误判为缓存过期。

把判定结果写进下一次复检

无论判定为缓存过期还是真正修复，都要留下可复用的记录：URL、两次请求时间、状态码、关键响应头、是否有回源日志。下一次复检时，先比对这些字段是否变化，而不是只看状态码。若字段未变而状态码变了，优先怀疑缓存或节点差异；若字段同步变化，才可认为修复稳定。这样处理，复检才有依据，也不会因为一次200就提前结束跟进。