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

测试死链接怎样排除缓存造成的假象？先分清404真伪再动手改

测试死链接时遇到404、跳转或旧内容，先不要直接改站内链接。缓存造成的假象，指的是一次检测结果来自浏览器、CDN、代理或抓取工具保存的旧响应，而源站当前状态已经不同。排除方法是用带随机参数的URL、无缓存请求头和不同网络环境交叉验证，再决定是否真的存在死链。

先查响应来源：状态码是谁返回的

要查的是：同一个URL在不同请求方式下返回的状态码是否一致。怎么查：用浏览器开发者工具的Network面板勾选Disable cache，再用命令行请求同一地址。结果说明：如果浏览器显示404而命令行返回200，可能是浏览器缓存或Service Worker返回了旧结果；如果两者都返回404，才更接近源站真实状态。

执行时注意，命令行请求要带-I只看响应头，例如curl -I https://example.com/page，但这里的域名只是占位示例，实际换成你要测的地址。若响应头里出现Age、X-Cache: HIT、CF-Cache-Status: HIT一类字段，说明中间缓存可能参与了响应，需要继续查源站。

用随机参数绕开缓存，但别把它当成最终结论

要查的是：去掉缓存键影响后，源站是否仍返回404。怎么查：在原URL后加一个无意义参数，例如?cachebust=20240613，再请求一次。结果说明：如果加参数后返回200，说明原URL很可能被缓存了旧响应；如果加参数后仍是404，说明源站本身可能已删除或改动了该资源。

适用条件：随机参数适合测试HTML页面和接口，不适合直接用来判断搜索引擎会抓取哪个版本。判断结果时，不要把“加参数能打开”当成死链已经修复，它只说明缓存层与源站响应不一致，真正要处理的是缓存刷新或源站配置。

检查CDN、反向代理和浏览器三层缓存

要查的是：缓存发生在哪一层。怎么查：按下面顺序逐层排除。

• 浏览器层：用无痕窗口或另一款未登录的浏览器访问，若结果变化，优先怀疑本地缓存或扩展。
• CDN或反向代理层：查看响应头中的缓存命中字段，并在控制台执行刷新缓存操作后重测。若刷新后恢复200，说明此前是边缘节点旧缓存。
• 源站层：直接请求源站IP或回源地址，若源站返回404，说明问题不在缓存，而在内容确实不存在。

结果说明：只有三层都返回404，才能把该URL判定为真实死链。任何一层返回200，都要先解决该层缓存或回源配置，再重新测试。

把抓取工具结果和真实访问分开看

要查的是：你用的死链检测工具是否读取了缓存结果。怎么查：用两个不同工具或两种请求方式测同一批URL，并记录每个URL的状态码、最终跳转地址和响应时间。结果说明：如果工具A报404、工具B报200，不能直接认定其中一方错误，要先看两者请求头、User-Agent和是否遵循跳转。

检查项包括：工具是否携带缓存绕过参数，是否跟随301和302，是否把软404当成404。对于测试死链接来说，最可靠的做法是以源站直接响应为准，工具结果只作为线索。站点地图不保证收录，robots.txt的抓取限制也不等于可靠的索引移除，这两点不能用来替代对真实响应状态的检查。

可执行清单：每步查什么、怎么查、结果说明什么

1. 查浏览器缓存：用无痕窗口打开目标URL。仍404则进入下一步；恢复200则清理本地缓存后复测。
2. 查中间缓存：用curl -I请求原URL，观察是否有缓存命中字段。有命中字段就刷新CDN缓存；没有则继续。
3. 查源站：给URL加随机参数再请求。仍404说明源站资源可能已不存在；返回200说明此前是缓存旧响应。
4. 查跳转链：用curl -IL跟随跳转，记录最终地址和状态码。最终地址404才是真实死链；中间跳转404可能只是旧规则残留。
5. 查工具差异：换一个检测工具或换网络环境复测。结果一致才可下结论；结果不一致就先查请求头和缓存层。

完成以上检查后，如果确认是缓存假象，下一步是刷新对应缓存并重新抓取一次；如果确认是真实死链，再决定做301跳转、恢复内容或从站内链接中移除。不要在没有区分缓存层和源站层之前批量修改链接。