死链扫描工具，怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /84e3cff4ee31.html
📄
死链扫描工具，怎样排除缓存造成的假象
用死链扫描工具查出的 404、超时或跳转异常，有一部分并不是服务器真实状态，而是扫描链路或中间层缓存返回的旧结果。排除缓存假象的核心做法是：对可疑 URL 追加一次性查询参数强制回源，再用不同网络与不同工具交叉验证，最后以源站访问日志和响应头作为判断依据。
先分清哪类结果可能是缓存造成的
缓存假象通常有几种表现：同一批 URL 连续扫描，两次结果不一致；扫描工具报 404，但浏览器直接访问正常；页面已恢复，工具仍报超时或 5xx；状态码正常但返回的是旧版内容。这些现象的共同点是“扫描端看到的结果”和“源站当前状态”不一致。
需要区分“可能原因”和“已经定位的原因”。CDN 边缘节点缓存、反向代理缓存、DNS 解析到不同节点、扫描工具自身的请求缓存，都可能产生上述现象，但不能仅凭一次异常就断定是缓存问题。判断的关键是看响应头中是否带有缓存命中标识，以及同一 URL 在不同节点上的返回是否一致。
用强制回源的方式验证真实状态
最直接的一步是给 URL 加一个每次不同的查询参数，绕过按完整 URL 缓存的中间层。例如原地址是：
https://example.com/page
改为：
https://example.com/page?cachebust=20240613a
每次更换参数值再请求。如果加参数后返回 200，而不加参数仍返回 404，说明中间层很可能缓存了旧的错误响应。如果加参数后依然 404，则更可能是源站本身的问题，缓存嫌疑下降。
适用条件：该方法对按完整 URL 做键的缓存有效；如果中间层忽略查询参数或按路径缓存，效果会打折扣，此时需要改用其他手段，比如直接请求源站 IP 并带上 Host 头，或从不同地理位置的节点分别请求。
两种处理方案的比较与选择
发现疑似缓存假象后，常见两种处理路径：
- 方案一：先清缓存再复扫。在 CDN 或反向代理控制台对可疑 URL 执行刷新，等待生效后重新扫描。适合确认是边缘缓存旧响应、且你能操作缓存层的情况。缺点是刷新有延迟，批量刷新可能影响正常流量。
- 方案二：先交叉验证再决定是否清缓存。用第二个工具、另一条网络线路、以及带参数的 URL 分别请求，确认源站真实状态后再处理。适合无法直接操作缓存层、或需要向他人证明问题归属的情况。缺点是耗时更长。
选择依据：如果你对缓存层有操作权限，且异常集中在少数 URL，方案一更快；如果异常量大、涉及多方协作，或你不确定缓存层归属，先用方案二定位，避免误清缓存掩盖真实故障。
复查时看什么才算排除干净
处理之后需要复查，判断缓存假象是否真正消除：
- 用不带参数的原始 URL 重新扫描，确认状态码与源站一致。
- 检查响应头中的缓存相关字段，确认返回的是回源后的新结果，而不是又一次命中旧缓存。
- 从至少两个不同网络环境请求同一 URL，确认结果一致。
- 对照源站访问日志，确认扫描请求确实到达了源站，而不是被中间层拦截或直接由缓存应答。
如果复查后仍不一致，说明问题可能不在缓存，而在 DNS 解析差异、防火墙策略或源站配置，需要换方向排查。
容易混淆的两个边界
第一，robots.txt 的抓取限制不等于索引移除，也不等于缓存控制。它影响的是爬虫能否抓取，不能用来解释死链扫描工具返回的缓存结果。第二，站点地图不保证收录，也不影响扫描工具对单个 URL 状态的判断。把这两者和缓存问题混在一起，会让排查方向跑偏。
下一步：挑出扫描结果中反复出现异常的 3 到 5 个 URL，按上面的加参数方法逐个验证，记录带参数与不带参数的状态码差异，再决定是否需要清缓存。
