404 not found：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /41fa180dd12e.html
📄
404 not found：多层缓存返回不同版本时怎样定位一致性问题
只有当你能先确认“同一请求在不同层得到不同响应”这一点真实存在时，才值得继续往下查；否则很可能把正常的缓存命中差异误判成故障。常见情况是：CDN 边缘返回 404 页面，回源到反向代理却拿到 200，应用层日志又显示资源已被删除。此时定位目标不是“谁对谁错”，而是找出哪一层持有过期副本、哪一层在重新验证时被错误放行。
先固定一个可复现的请求身份，再比较各层响应
多层缓存不一致的核心难点是每层看到的请求并不完全相同。你需要先固定一个可复现的请求身份，通常包括完整 URL、Host、请求方法、Accept-Encoding、Cookie 中与灰度或登录态相关的字段，以及是否带条件请求头。把同一个身份依次打到边缘、中间代理和源站，记录状态码、响应头中的缓存标记和实际返回体长度。若三处状态码不同，先不要改配置，而是确认哪一层在什么时间点写入了这份副本。
一个实际动作是：在边缘层临时绕过缓存发起一次回源请求，观察源站返回是否与边缘当前返回一致。如果绕过缓存后源站也返回 404，说明问题在源站数据或路由，而不是缓存版本；如果源站返回 200，则边缘或中间层持有旧副本，下一步应转向缓存键、TTL 和失效通知的检查。这个动作的价值在于把排查方向从“缓存问题”缩小到某一层。
区分三种会导致版本分叉的原因
同样是“不同层返回不同版本”，原因可能完全不同，处理方式也不同。
- 缓存键设计不一致。边缘按 URL 加查询串缓存，中间层按 URL 加 Cookie 缓存，源站按用户身份返回不同内容。此时同一 URL 在不同层会命中不同对象，表现为有的层 404、有的层 200。验证方法是逐层打印实际参与缓存的键，而不是只看 URL。
- 失效通知没有到达全部层。内容被删除或改路径后，源站发出清除指令，但某一层因网络、权限或接口变更没有收到。结果是该层继续返回旧版本。验证方法是查清除指令的发送记录与各层接收记录，确认缺口在哪一段。
- 条件请求被错误处理。某层带 If-None-Match 或 If-Modified-Since 回源，源站返回 304，但该层本地没有可用的对应实体，于是回退到旧副本或错误页。这种情况常被误认为“源站返回了 404”。验证方法是单独观察条件请求的完整往返，而不是只看最终状态码。
一个会推翻上述结论的反例
如果各层返回的 404 页面内容、响应头甚至时间戳完全一致，那么“多层缓存版本分叉”这个前提就不成立，真正的问题更可能是源站路由或资源本身已不存在。此时继续查缓存只会浪费时间。判断依据是：缓存分叉通常伴随至少一项差异，例如 ETag、Last-Modified、Age、X-Cache 状态或响应体长度。若这些字段完全一致，应转向检查源站的重写规则、上游服务健康状态和最近的内容变更记录。
把定位结果转成下一步动作
当你确认是某一层持有旧副本后，下一步不是直接清空全部缓存，而是先判断影响范围：是单个 URL、一组路径，还是整个缓存键空间。若只是单个 URL，可先对该 URL 做定向失效并复测；若是一组路径，检查失效规则是否覆盖了这批路径；若范围无法界定，再考虑按层逐步失效，并在每一步后复测同一请求身份。
需要注意，抓取量或请求量暂时归零并不能单独证明处理正确，它也可能来自流量波动、监控采样变化或上游屏蔽。因此复测应以固定请求身份的状态码和响应头为准，而不是以流量曲线为准。若你同时依赖 robots.txt 限制抓取，要记住它只影响抓取行为，不等于可靠的索引移除；站点地图也不保证收录。这些信号可以辅助判断影响面，但不能替代逐层响应比对。下一步动作应是：固定请求身份，逐层记录响应，定位持有旧副本的层，再做定向失效并复测同一身份。
