死链检查，怎样排除缓存造成的假象

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

死链检查，怎样排除缓存造成的假象

死链检查时遇到缓存造成的假象，核心处理办法是：不要直接采信第一次请求返回的状态码，而是用带随机查询参数的URL重新请求一次，并在响应头中确认是否命中缓存。如果两次结果不一致，第一次的404、410或连接失败很可能是缓存副本，而不是源站真实状态。

先看一个假设例子

假设某个项目曾把/old-page配置为410，后来改为301跳转到新页面。此时用死链检查工具扫描，工具报告/old-page返回410。原因可能是CDN或反向代理仍缓存着旧的410响应，源站其实已经返回301。判断方法是在URL后加一个无意义参数，例如/old-page?check=20240101，让缓存键发生变化。如果新请求返回301，说明之前看到的410是缓存假象；如果仍返回410，才需要继续查源站配置。

用响应头判断是否命中缓存

仅看状态码不够，还要看响应头。常见的缓存命中线索包括Age大于0、X-Cache: HIT、CF-Cache-Status: HIT等，具体字段取决于你使用的缓存层。这些字段不是所有服务都会返回，所以判断时要结合以下检查项：

需要注意，Age为0不代表一定没有缓存，某些缓存层不回传该字段；反过来，看到X-Cache: HIT也不代表源站一定正常，只说明这次响应来自缓存。

绕过缓存做二次确认

确认源站真实状态，可以按以下顺序执行：

  1. 在URL后追加唯一查询参数，例如时间戳或随机字符串，强制缓存层回源。
  2. 如果条件允许，直接请求源站IP并带上Host头，跳过CDN和反向代理。
  3. 对比两次响应的状态码、Location头和响应体长度，判断差异来自缓存还是源站。
  4. 在缓存层对该URL执行刷新或清除，再重新请求一次，观察状态码是否变化。

这里有一个常见错误：只清除了浏览器缓存就认为问题解决。浏览器缓存、CDN缓存、反向代理缓存和服务端对象缓存是不同层，死链检查工具通常不经过浏览器，所以清浏览器缓存对工具扫描结果没有影响。另一个错误是把robots.txt的抓取限制当成索引移除手段，它只能阻止抓取，不能可靠地让已收录页面消失，也不能解释状态码层面的缓存假象。

哪些情况不适合直接判定为缓存问题

加参数后状态码仍然不变，就不能继续用缓存解释。此时要检查源站路由、重定向规则、应用层异常和DNS解析。如果返回的是301或302，还要看Location指向的地址是否可达；如果返回5xx，则属于服务端错误，与死链检查中的缓存假象不是同一类问题。另外，站点地图提交和HTTPS配置都不能保证收录或排名，也不能作为判断死链是否真实存在的依据。

下一步：挑出扫描结果中所有返回404、410或连接失败的URL，逐个加随机参数重新请求，并把两次的状态码和缓存相关响应头记录在同一张表里，再决定哪些需要修改源站配置，哪些只需刷新缓存。

图1 图2
nginx