网站死链检测：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4c2103230836.html
📄
网站死链检测：多层缓存返回不同版本时怎样定位一致性问题
先给结论：不要从“哪一层坏了”入手，而要从“同一请求在各层看到的是哪个版本”入手。做法是固定一个 URL 和一组请求头，依次绕过各层缓存取响应，把状态码、最终跳转地址、响应头里的版本或时间标识、正文中的特征字符串记成一条链。链上第一个与其他层不一致的位置，就是优先怀疑的层；如果所有层一致但结果仍与预期不符，问题在源站内容或跳转规则，而不在缓存。
这个判断只在多层结构确实存在时成立：浏览器缓存、CDN、反向代理、应用层缓存、对象存储各管一段，且每层都有自己的键和过期策略。若站点只有单层缓存，本方法不适用，应回到源站配置本身排查。
条件一：各层返回内容不同，但状态码相同
这种情况最容易被误判成“死链已修复”。假设旧内容已下线，源站对旧地址返回 410，但 CDN 仍缓存着下架前抓到的 200 页面，浏览器拿到的就是 200 加旧正文。此时用站点地图或抓取工具跑一遍，会看到一片正常，与真实状态相反。
定位动作：对同一个 URL 分别请求源站直连地址、回源地址和对外地址，比较正文中的特征字符串，比如旧标题、旧编号、旧跳转目标。哪一层的正文与源站最新版本不同，就先处理哪一层。结果会直接决定下一步：若只有边缘节点不一致，动作是清理该 URL 的缓存并确认回源；若源站本身就是旧版本，清理缓存没有意义，要先去改发布流程或数据源。
注意一个反直觉现象：清理缓存后请求量或抓取量突然归零，不能证明处理正确。也可能是回源失败、限流或抓取工具自身中断，需要再看一次直连源站的响应来区分。
条件二：各层内容一致，但跳转链或响应头不一致
当正文相同、状态码也相同，问题往往藏在跳转链和缓存指令里。旧合作关系退出后，一批旧路径需要 301 到新页面，但某层缓存把 301 连同旧目标一起存住，后面所有请求都沿着旧目标走，形成看似正常的循环或长链。
定位动作：逐层取响应头，记录 Location、Cache-Control、Age、ETag 或 Last-Modified，以及正文首段特征词，拼成一条从边缘到源站的链。链上第一个 Location 与其他层不同的位置即为分歧点。若分歧出现在边缘层，处理该 URL 的缓存并验证回源；若分歧出现在源站，说明跳转规则本身没更新，此时清缓存只是让旧规则重新被抓一遍。
这一步的取舍在于：对仍被外部引用的旧路径，保留 301 比直接 410 更合适，因为链接价值和用户路径还在；对确认无引用、无搜索价值的旧路径，410 更干净，但前提是确认各层都已同步，否则会出现“部分用户看到 410、部分看到 200”的混合状态。
把检测结果分成两类再决定动手顺序
- 版本分歧类：同一 URL 在不同层返回不同正文或不同跳转目标。先定位分歧层，再决定是清缓存还是改源站。
- 一致但错误类：所有层返回同一结果，但该结果与预期不符。问题在源站规则、发布流程或数据源，缓存只是忠实转发。
建议先跑版本分歧类，因为它的影响面会随缓存过期时间扩大；一致但错误类通常稳定，可以排在其后。每次只改一层，改完立刻重取同一条链，否则无法判断是哪次动作生效。
需要留意的例外与前提
机器人协议里的抓取限制不等于可靠的索引移除，站点地图也不保证收录，因此不要用“已提交站点地图”当作旧内容已退出的证据。HTTPS 同样不代表内容版本正确。不同搜索引擎对缓存和跳转的处理需要分别核查，不能拿一个引擎的表现推断另一个。
如果旧系统或旧合作关系仍有一部分内容需要保留，先划出保留清单，再对清单外的路径统一走上面的链路比对；保留部分单独设缓存策略，避免退出动作误伤仍在用的页面。完成一轮比对后，把每个 URL 的分歧层、处理动作和复测结果记下来，下一次出现同类问题时可以直接从对应层开始，而不必重新跑全链路。
