死链接检测：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6960e07e3f45.html
📄
死链接检测：多层缓存返回不同版本时怎样定位一致性问题
先给结论：如果同一路径在不同缓存层返回不同状态码或不同跳转目标，先用带缓存旁路的单层探测把每一层分开测，再决定是改缓存键、改回源，还是改死链接检测规则。只有当所有层都返回同一版本时，死链接检测结果才可信；否则你测到的“死链”可能只是某一层缓存里的旧副本。
先分清两种不一致：状态码不一致和跳转目标不一致
多层缓存通常包括浏览器缓存、CDN 边缘节点、反向代理缓存和应用层缓存。它们返回不同版本时，表现可以归为两类。
- 状态码不一致：同一 URL 在 A 层返回 200，在 B 层返回 404 或 410。常见原因是某一层缓存了旧的成功响应，而回源已经改成 404，或者反过来，回源已恢复但边缘仍保留旧的 404。
- 跳转目标不一致：同一 URL 在 A 层跳到新地址，在 B 层仍跳到旧地址。常见原因是重定向规则更新后，旧缓存未失效，或不同层使用了不同的缓存键。
这两类问题的排查顺序不同。状态码不一致优先查回源和缓存 TTL；跳转目标不一致优先查缓存键和重定向规则版本。
用带缓存旁路的探测把每一层分开
不要用同一个请求反复测。给每一层加一个可区分的请求头或查询参数，让缓存键发生变化，然后逐层观察返回。
- 先测回源：绕过 CDN 和反向代理，直接请求应用服务器，记录状态码和跳转目标。
- 再测边缘：请求 CDN 节点，带上一个唯一查询参数，观察是否与回源一致。
- 最后测浏览器侧：用无缓存模式或新会话请求，观察是否与边缘一致。
如果回源返回 404，而边缘返回 200，说明边缘缓存了旧的成功响应。下一步动作是确认该 URL 的缓存 TTL 和刷新机制，而不是立刻把它加入死链接清单。刷新边缘缓存后重新探测，如果边缘也返回 404，才可以把该 URL 标记为真实死链。
反过来，如果回源返回 200，而边缘返回 404，说明边缘缓存了旧的错误响应。这种情况下，死链接检测工具会把正常页面误报为死链。下一步动作是检查边缘缓存的错误响应 TTL，必要时主动清除该路径的缓存，再重新探测。
一个反例：所有层都返回 404 也不代表处理正确
假设你发现某路径在所有层都返回 404，于是把它从死链接清单中移除，认为问题已经解决。但如果这个 404 是因为回源配置错误导致的，而缓存只是忠实缓存了这个错误，那么所有层一致反而会掩盖真正的故障。
判断依据不是“是否一致”，而是“回源返回的 404 是否与业务预期一致”。你可以用一个已知正常的 URL 做对照：如果对照 URL 在回源也返回异常，说明问题在回源配置或应用层，而不是缓存层。此时下一步动作是检查应用路由和回源配置，而不是继续调整缓存。
把检测动作和缓存刷新动作分开记录
死链接检测和缓存刷新是两个独立动作，混在一起会导致无法判断哪一步改变了结果。建议在检测记录中至少保留三项：探测时是否绕过缓存、探测到的状态码或跳转目标、该次探测对应的缓存层。
一个假设的例子：某路径在边缘返回 301 跳到旧地址，回源返回 301 跳到新地址。你先刷新边缘缓存，再重新探测，边缘也跳到新地址。此时可以确认问题是旧缓存未失效，而不是重定向规则写错。下一步只需要确认缓存刷新策略是否覆盖该路径，不需要改重定向规则。
如果刷新边缘缓存后，边缘仍然跳到旧地址，则说明缓存键可能包含了你不曾预期的维度，或者刷新请求没有命中正确的缓存节点。下一步动作是检查缓存键构成和刷新请求的覆盖范围，而不是重复刷新。
什么时候可以停止排查
当回源、边缘和浏览器侧返回同一状态码和同一跳转目标，并且该结果与业务预期一致时，可以停止排查。此时死链接检测的结果才可以直接用于后续处理。
如果三者仍然不一致，或者回源本身返回的结果与业务预期不符，则不应把该 URL 标记为已确认死链或已确认正常。下一步动作是回到回源配置或应用路由层继续定位，而不是在缓存层反复调整。
