死链检查方法，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80bd5e97c90c.html
📄
死链检查方法，异常恢复后怎样区分缓存过期与真正修复
当一条死链被处理后重新返回正常状态，最稳妥的区分方式是：先确认响应是否来自缓存层，再确认源站是否真的返回了200，最后用带随机参数的请求或强制回源的方式复核。如果源站仍返回404或410，只是缓存尚未过期，那就不是真正修复；如果源站已返回200，且缓存层已更新，才算修复生效。
先看响应头，判断是谁在回答你
异常恢复后，第一步不是直接看页面能不能打开，而是看响应头里有没有缓存命中标记。常见的判断依据包括 Age、X-Cache、CF-Cache-Status、X-Proxy-Cache 这类字段。如果 Age 大于0，说明当前响应来自缓存，不能代表源站状态。此时即使状态码是200，也只能说明缓存里存的是旧的成功响应，不能推出死链已经修复。
如果响应头里没有明显缓存标记，也不等于一定回源。部分CDN或反向代理会隐藏这些字段。这时需要换一种方式验证，而不是直接下结论。
用随机参数请求，绕过缓存看源站
在URL后追加一个无意义的查询参数，例如 ?cachebust=20240613a，再发起请求。多数缓存会把带不同查询参数的URL视为不同对象，从而回源。如果这次返回404或410，说明源站仍然是死链状态，之前看到的200只是缓存未过期。如果这次返回200，并且页面内容正确，才说明源站已恢复。
这个动作的结果会直接影响下一步：源站仍404，就继续修源站；源站已200但缓存仍返回旧状态，就进入缓存刷新或等待过期阶段。两者处理路径完全不同，不能混在一起。
缺少完整数据或权限时的最小动作
如果你没有CDN后台权限，也拿不到源站日志，仍然可以做两件事。第一，用 curl -I 分别请求原始URL和带随机参数的URL，对比状态码和响应头。第二，换一个网络环境或换一个出口IP再请求一次，观察结果是否一致。如果原始URL返回200、带随机参数返回404，基本可以判断是缓存过期问题，而不是真正修复。
但要注意，这个结论有边界。如果源站对带参数的请求做了特殊处理，比如直接返回404，那随机参数法会失效。此时可以改用一个不改变路径的请求头，例如 Cache-Control: no-cache，观察响应是否变化。仍然无法判断时，只能标记为“待确认”，不能当作已修复。
缓存过期与真正修复的区分清单
- 原始URL返回200，带随机参数返回404或410：缓存未过期，源站仍是死链。
- 原始URL返回200，带随机参数也返回200，且内容正确：源站已恢复，缓存也已更新或回源。
- 原始URL返回200，带随机参数返回200，但内容仍是旧页面或错误页：源站可能返回了软404，需要检查页面正文和标题。
- 原始URL返回301或302，带随机参数也返回301或302：需要继续跟踪跳转目标，不能只看第一跳状态码。
- 原始URL返回200，但响应头里
Age很大，且带随机参数返回404：缓存层仍在提供旧的成功响应，源站未修复。
一个假设例子：同一URL的两次请求
假设某页面在三天前被删除，源站返回410。CDN缓存了更早的200响应，缓存有效期设为7天。今天你请求原始URL，看到200，误以为已修复。但带随机参数请求后返回410，说明源站仍是删除状态。此时正确动作是继续处理源站，而不是去刷新缓存。反过来，如果带随机参数也返回200，且页面正文与预期一致，才可以把该URL标记为已恢复，并进入下一步的索引状态观察。
这个例子里的数字只用于说明比较方法，不代表任何真实缓存策略或平台行为。实际判断时，应以你手中页面返回的响应头和状态码为准。
不能从单次正常响应推出的结论
一次200响应不能证明死链已修复，也不能证明搜索引擎会重新收录。缓存过期只是时间问题，源站修复才是根本。即使源站已返回200，也需要继续观察该URL在后续抓取中的状态，不能因为一次正常响应就停止检查。如果缺少日志和索引数据，至少要把“源站已恢复”和“缓存已更新”分开记录，避免把缓存过期误判为修复完成。
