死链接检测：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c0f2bfbfdba9.html
📄
死链接检测：异常恢复后怎样区分缓存过期与真正修复
结论要先加条件：如果你能拿到源站日志或回源记录，缓存过期与真正修复可以直接区分；如果只有第三方检测结果，最稳妥的做法是把“状态码变好”当作待验证信号，而不是修复完成的证据。缓存过期通常表现为同一 URL 在不同节点、不同时间返回不一致；真正修复则应在源站层面稳定返回目标状态，并且旧错误不再随节点变化复现。
先看一个会推翻结论的反例
假设你检测到某个 URL 从 404 变成 200，就判断“已经修好”。这个判断可能被反向代理或 CDN 的缓存策略推翻：源站仍然返回 404，只是边缘节点缓存了一份旧的 200 响应，或者缓存了重定向后的结果。此时你看到的“恢复”来自缓存层，而不是内容层。
反过来说，如果源站已经修好，但检测节点命中了旧的 404 缓存，你会看到“仍然坏着”的假象。两种方向的误判都成立，所以单次状态码变化不能作为结论。
用响应头与多节点结果做交叉判断
在没有日志权限时，仍可执行一个最小动作：对同一 URL 连续请求，并记录响应头中的缓存相关字段与返回状态。重点不是记住某个字段名，而是观察一致性。
- 若多个不同网络位置的检测结果在同一时间段内不一致，缓存未统一的可能性更高。
- 若响应头显示命中缓存，且缓存时间早于你完成修复的时间，应优先怀疑旧缓存仍在生效。
- 若请求绕过缓存后源站返回目标状态，而带缓存请求仍返回旧状态，说明修复可能已完成，但缓存尚未过期。
- 若绕过缓存后源站仍返回错误状态，则修复本身没有生效，与缓存无关。
这里的关键动作是“绕过缓存再请求一次”。它的结果直接决定下一步：源站正确而缓存错误，下一步是等待过期或按规则刷新；源站错误，下一步是回到内容或配置层继续修。
缓存过期与真正修复的可区分证据
把两类现象放在一起对照，比单独看一个状态码更可靠。
- 缓存过期：错误状态随时间或节点减少，源站回源结果与边缘结果不一致，重复请求可能得到不同结果。
- 真正修复：源站稳定返回目标状态，多个节点结果趋于一致，旧错误不再复现，且这种一致性能在缓存周期之外保持。
需要提醒的是，抓取量或请求量归零不能单独证明处理正确。它还可能来自检测任务停止、robots.txt 限制、网络中断或目标地址被临时屏蔽。robots.txt 的抓取限制也不等于可靠的索引移除，站点地图同样不保证收录。这些现象只能作为辅助线索，不能替代源站状态验证。
缺少权限时的最小验证与下一步
如果你既没有源站日志，也没有缓存刷新权限，可以按下面顺序执行，并把每一步结果作为下一步的依据：
- 记录当前检测结果、检测时间与所用网络位置，作为基线。
- 对同一 URL 发起一次带随机查询参数的请求，尽量绕开已有缓存；若返回目标状态，说明源站可能已修复，问题集中在缓存层。
- 间隔一段时间后重复检测，观察结果是否从“部分节点正常”收敛为“多数节点一致”。收敛通常支持缓存过期解释，持续分裂则说明源站或缓存配置仍有问题。
- 若条件允许，检查页面内容是否已替换为预期内容，而不仅是状态码变化；内容与状态同时正确，才更接近真正修复。
这套动作只能帮你缩小范围，不能证明搜索引擎已经重新处理该 URL。HTTPS 不保证安全无漏洞或排名，不同搜索引擎对同一 URL 的支持情况也须分别核查。下一步应把“源站是否稳定返回目标状态”作为唯一硬条件，再决定是继续等待缓存过期，还是回到修复流程。
