死链接检测，怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0523bb3e8caa.html
📄
死链接检测，怎样排除缓存造成的假象
死链接检测时出现“假死链”，最常见的原因不是链接真的坏了，而是你看到的是缓存副本：浏览器缓存、CDN 缓存、代理缓存或抓取工具自身的缓存，都可能让一个已经修复或已经变化的地址继续显示旧状态。要排除这类假象，核心做法是绕过缓存重新请求，并用响应状态码、最终地址和响应头中的缓存信息交叉判断，而不是只看一次页面提示或一次工具结果。
一个假设例子：修复后仍报 404
假设某团队在协作中收到一条死链接报告：/old-page 返回 404。负责人把它改成了 301 跳转到新页面，本地打开正常，但检测工具和部分同事仍然看到 404。此时不能直接判定“修复失败”，因为至少存在三种解释：一是工具或浏览器仍在使用旧缓存；二是 CDN 边缘节点尚未刷新；三是源站确实没有生效，只是本地因为缓存而显示正常。
要区分这几种情况，可以按下面步骤执行：
- 先用带随机查询参数的地址请求，例如在 URL 后加
?cachebust=20240101。查询参数不同，缓存键通常不同，更容易拿到源站或新缓存版本。 - 再用命令行工具查看响应头，重点看状态码、
location和cache-control、age、x-cache一类字段。若状态码仍是 404，说明问题可能不在浏览器缓存。 - 分别从不同网络环境请求，例如办公室网络、手机热点和一台未访问过该地址的设备。如果只有某一环境异常，优先怀疑该环境中的代理或本地缓存。
- 如果使用 CDN，检查缓存刷新记录和回源日志。刷新请求已提交不等于所有节点立即生效，需要看实际回源结果。
常见错误是只刷新浏览器就下结论。浏览器强制刷新只能影响本地，不能清除 CDN 或反向代理缓存；反过来，CDN 刷新也不能证明源站已经正确配置。判断结果应当以“绕过缓存的请求是否返回预期状态”为准。
看响应头，而不是只看页面
死链接检测工具给出的结果，通常来自一次 HTTP 请求。要排除缓存假象，必须看这次请求的响应头。可以重点检查以下项目：
- 状态码：200、301、302、404、410 的含义不同。301 和 302 是跳转，不是死链；404 和 410 才更接近“不可用”。
- 最终地址：如果请求经过多次跳转，要看最终落到哪个 URL。缓存可能让中间跳转被省略或保留旧跳转。
- 缓存相关字段：
cache-control决定是否可缓存、缓存多久；age表示该响应在缓存中已存在多久；etag和last-modified可用于判断内容版本。 - 缓存命中标识：不同 CDN 的命中标识字段不同，不能假定所有服务都叫同一个名字，应以实际响应头为准。
如果响应头显示 age 很大，而 cache-control 又允许长时间缓存，那么你看到的很可能是旧副本。此时应刷新缓存或等待过期，再重新检测。如果响应头显示没有缓存，但状态码仍是 404，就应转向检查源站路由、重写规则和服务端配置。
多人协作时怎样交付才不返工
多人协作中，死链接检测最容易返工的地方，是每个人看到的缓存状态不同，却把不同结果当成同一事实。要减少这种返工，交付时应把“检测条件”写清楚，而不是只写“已修复”或“仍报错”。
一份清楚的记录至少包含：检测时间、请求的完整地址（含查询参数）、使用的网络环境或工具、返回状态码、最终跳转地址、关键响应头，以及是否绕过缓存。这样下一位同事可以复现同一条件，而不是重新猜。
如果团队使用工单或表格协作，可以把“缓存是否已刷新”和“源站是否已修复”分成两个检查项。前者由负责 CDN 或代理的人确认，后者由负责源站配置的人确认。两项都完成，才把死链接标记为关闭。这样能避免把缓存未刷新误判为修复失败，也能避免把源站未修复误判为缓存问题。
工具结果与真实状态的核对方法
死链接检测工具本身也可能缓存结果，或者按固定周期抓取。工具显示 404 时，不要直接把它当成最终结论。可以先用工具提供的“重新抓取”或“忽略缓存”选项；如果没有该选项，就手动请求同一地址并对比结果。
核对时还要区分搜索引擎、网页搜索、平台推荐和付费广告的不同系统。一个地址在某个抓取工具中返回 404，不代表所有搜索引擎都会同样处理；反过来，某个搜索引擎已收录，也不代表该地址当前一定可访问。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些系统各自独立，不能用其中一个的结果替代另一个的核查。
对于 HTTPS 地址，也不要因为证书正常就认定链接一定有效。HTTPS 不保证安全无漏洞或排名，它只说明传输层加密生效。死链接检测关注的是资源是否可访问，证书状态只是其中一个检查维度。
下一步：建立可复现的检测记录
要真正排除缓存造成的假象，下一步不是反复刷新页面，而是为每条疑似死链建立一份可复现的检测记录：记录绕过缓存的请求地址、响应状态码、最终地址和缓存头，并注明由谁在什么环境下验证。这样下一次出现同样报告时，团队能直接判断是缓存未更新、源站未修复，还是工具结果滞后，而不是重新争论一遍。
