死链检测，怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3ee8ebfdb626.html
📄
死链检测，怎样排除缓存造成的假象
死链检测中遇到缓存造成的假象，核心做法是：不要只凭一次请求的结果下结论，而是用带缓存规避参数的请求、不同的请求头与来源、以及服务器日志三方对照，确认返回状态码是源站真实响应，还是缓存层、CDN、浏览器或代理给出的旧结果。下面从一个假设例子展开，说明具体步骤和常见错误。
一个假设例子：同一URL两次检测结果不同
假设你负责的站点上有一个页面 /old-page.html。运营反馈说它已经下线，但你的检测工具报告它是 200。你手动在浏览器打开，也显示正常。此时可能有三种解释：源站其实没删；源站删了但缓存层仍返回旧页面；检测工具的请求被重定向到别的正常页面。这三种原因不能混为一谈，需要分别取证。
先记录现象：检测时间、使用的工具或命令、返回的状态码、响应头中的 Cache-Control、Age、X-Cache、Via 等字段、以及最终的响应体是否为你预期的旧页面内容。这些字段是判断缓存是否介入的第一手证据。
用请求头与参数区分缓存响应和源站响应
缓存规避不是加一个随机参数就万事大吉，关键是让请求绕过缓存层，同时观察响应头变化。可以按顺序执行：
- 用
curl -I请求原始 URL，记录状态码和缓存相关响应头。 - 再请求同一个 URL 并附加一个不会命中缓存的查询串，例如
?cachebust=20240101，对比两次的状态码与响应头。 - 如果两次结果不同，说明缓存层很可能在起作用；如果两次相同，仍需检查请求头是否被缓存层归一化。
- 发送
Cache-Control: no-cache请求头，观察源站是否返回不同的状态码。
注意：no-cache 是要求缓存向源站验证，不是完全不使用缓存；no-store 才是要求不存储。不同 CDN 和反向代理对这些头的处理方式不同，所以不能只看一个头就下结论，要结合 Age 是否大于 0、X-Cache 是否为 HIT 等线索。
换来源、换解析、换工具交叉验证
缓存可能存在于浏览器、本地代理、公司出口、CDN 边缘节点等多个位置。要排除假象，至少做三类交叉验证：
- 换网络来源：用一台不在同一出口的机器或移动网络请求同一 URL，看状态码是否一致。
- 换请求身份：用不同的 User-Agent 请求，观察是否返回不同结果；某些缓存按 UA 分桶。
- 换检测工具：用命令行工具和在线检测服务分别请求，记录各自看到的状态码与响应头。
如果只有你的机器看到 200，其他来源看到 404，那么问题更可能出在本地或路径上的缓存，而不是源站。反过来，如果所有来源都看到 200，就需要回到源站配置，确认这个 URL 是否真的被移除，或者是否被规则重写到了别的页面。
看服务器日志，确认源站是否真的收到请求
缓存假象最可靠的排除方式之一，是查源站访问日志。在检测请求发出的同一时间窗口内，搜索该 URL 的记录：
- 如果日志里根本没有这次请求，说明请求被缓存层或中间层拦截，没有到达源站。
- 如果日志里有请求，且源站返回 404，但客户端看到 200，说明缓存层返回了旧响应。
- 如果日志里源站返回 200，那这个 URL 在源站层面可能并未真正下线，需要检查路由、重写或默认页配置。
日志时间要对齐时区，并注意日志可能只记录部分状态码或经过采样。若站点使用 CDN，CDN 自身的日志和源站日志要分开看，两者对不上时，优先以源站日志判断源站行为，以 CDN 日志判断边缘缓存行为。
常见错误与判断结果
常见错误包括：只刷新浏览器就认为缓存已排除；只加随机参数但不看响应头；把 robots.txt 的抓取限制当成索引移除手段；把站点地图当成收录保证。这些做法都不能证明死链的真实状态。判断结果时，可以按以下条件归类：
- 加缓存规避参数后状态码变为 404，且响应头显示未命中缓存：倾向判定为缓存假象。
- 所有来源、所有请求头都返回 200，且源站日志也返回 200：倾向判定为源站未真正移除。
- 状态码在 200、301、404 之间跳变，且伴随重定向链：需要先梳理重定向规则，再判断哪一步是缓存造成的。
只有把请求证据、响应头证据和服务器日志证据对齐，才能把“可能是缓存”升级为“已经定位为缓存”。在此之前，不要急于批量判定死链或提交移除请求。
下一步：挑一个你怀疑存在缓存假象的 URL，按上面的顺序做一次带响应头和日志对照的检测，把三次请求的结果并排记录，再决定是否需要清理缓存或修正源站配置。
