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

死链测试工具怎样排除缓存造成的假象：先分清谁在返回旧结果

用死链测试工具扫描时，如果某个链接已经被删除或改址，工具却仍报告正常，最常见的原因是请求链路中有人返回了缓存副本：浏览器缓存、CDN 边缘缓存、反向代理缓存，或工具自身的上次扫描结果。要排除假象，核心动作是让检测请求绕过缓存，并确认响应来自源站，而不是中间层。

先观察：假象通常有哪几种表现

缓存造成的误判不是一种固定现象，需要先看证据再下结论。常见表现包括：

• 同一 URL 在浏览器无痕窗口打开是 404，在普通窗口打开却正常。
• 工具第一次扫描报 200，隔一段时间再扫仍报 200，但源站日志里没有对应请求。
• 带随机查询参数的 URL 返回 404，去掉参数后返回 200。
• 不同地区或不同网络下结果不一致，一个节点报正常，另一个节点报失效。

这些现象可能由缓存引起，也可能由重定向规则、CDN 回源失败、WAF 拦截或工具超时造成。不要把某一种表现直接认定为缓存，先做下面的对照测试。

判断：用一次对照请求确认响应来源

最直接的判断方法是比较“带缓存绕过”和“不带绕过”的响应。以命令行工具为例，可以分别执行两次请求，观察状态码和响应头：

curl -I https://example.com/old-page

curl -I -H "Cache-Control: no-cache" -H "Pragma: no-cache" https://example.com/old-page

重点看响应头里是否出现 X-Cache: HIT、Age 大于 0、CF-Cache-Status: HIT 这类字段。如果第二次请求仍返回 200，但源站访问日志中没有记录，说明结果很可能来自中间缓存。如果两次都返回 404，则缓存不是主因，应转向检查工具配置或源站规则。

还可以加一个随机查询参数做交叉验证，例如请求 https://example.com/old-page?cachebust=20240101。多数缓存会把带不同查询串的请求视为不同资源，从而回源。如果带参数返回 404、不带参数返回 200，缓存嫌疑就很高。但要注意：部分 CDN 会忽略指定查询参数，这种方法只能作为参考，不能单独定论。

处理：让死链测试工具真正打到源站

确认是缓存问题后，按链路逐层处理，而不是只在工具里反复重扫。

1. 在工具中开启“忽略缓存”或“强制回源”类选项。不同工具的叫法不同，需要查看其请求设置，确认它是否发送了 Cache-Control: no-cache 或等价请求头。
2. 如果工具不支持绕过缓存，改用命令行或支持自定义请求头的检测方式，对可疑 URL 单独复测。
3. 在 CDN 或反向代理层对该 URL 执行缓存刷新。刷新只影响被刷新的资源，不改变源站内容；如果源站本身仍返回 200，刷新后依然会报正常。
4. 检查源站是否真的删除了页面。删除文件不等于返回 404，有些服务器配置会把不存在的路径重写到首页并返回 200，这属于软 404，和缓存无关。
5. 确认 robots.txt 没有阻止检测工具抓取目标路径。抓取限制不等于索引移除，也不能解释缓存返回的旧状态码，但会干扰部分工具的扫描结果。

处理顺序建议是：先绕缓存复测，再刷新中间层，最后核对源站响应。跳过前两步直接改源站，容易把不是缓存的问题误判成缓存。

复查：换条件重扫并记录判断依据

处理完成后，不要只看一次扫描结果。复查时至少改变一个条件：

• 换网络或换出口 IP 再扫一次，排除单节点缓存。
• 等待缓存 TTL 过期后再扫，确认结果是否稳定。
• 同时用带参数和不带参数的 URL 对比，观察状态码是否一致。
• 查看源站访问日志，确认检测请求确实到达了源站。

判断标准可以简化为：绕过缓存的请求返回什么状态码，就以什么状态码为准；如果绕过缓存后返回 404，而普通请求返回 200，说明问题在缓存层，不在页面本身。如果绕过缓存后仍返回 200，需要继续检查服务器重写规则和软 404 配置。

下一步可以做什么

挑一个当前被工具报告为正常的可疑 URL，分别执行带缓存绕过和不带绕过的两次请求，记录状态码与响应头中的缓存字段。两组结果不一致时，优先处理缓存层；结果一致时，转向检查源站的重写规则和软 404。这样能把“工具说正常”变成“我知道它为什么说正常”。