404错误页面：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0208945ffcfa.html
📄
404错误页面：多层缓存返回不同版本时怎样定位一致性问题
当同一个URL在CDN、反向代理、应用层缓存和浏览器缓存之间出现“有的返回404、有的返回200”的分歧时，先把问题定义为“哪一层缓存持有哪个版本”，再决定是保留某一层、改写缓存键还是让某一层退出。判断依据不是谁报错，而是每一层能否提供可核对的证据：响应状态、缓存键、TTL、Vary头和回源日志。缺少这些证据时，任何“清缓存”都只是碰运气。
先确认分歧是否真实存在，而不是观测位置不同
多层缓存下最常见的假象，是不同角色看到的其实是不同对象。CDN边缘节点按URL缓存，反向代理可能按Host加路径缓存，应用层可能按用户会话或设备类型缓存。同一路径在带Cookie、带查询参数、带不同Accept-Language时，可能命中不同缓存键。此时有人看到404，有人看到200，并不矛盾。
可核对的证据包括：请求是否带Cookie、查询串、自定义头；响应的Age、X-Cache、CF-Cache-Status一类缓存指示头；以及各层日志中的缓存键。若这些字段缺失，先补观测，再谈定位。
假设某路径在边缘返回404，回源却返回200。若边缘日志显示缓存键包含设备类型，而回源日志只记录路径，那么分歧可能来自缓存键设计，而非源站内容错误。这个假设成立的前提是两层日志能对齐时间戳和请求标识；若无法对齐，先加请求ID，而不是直接清空缓存。
保留、改写还是退出：三种取舍的适用前提
定位到具体层之后，处理方式通常落在三种取舍上，各自成立条件不同。
- 保留：当某一层缓存返回的版本才是期望版本，且其他层只是短暂旧数据时，保留该层并等待TTL自然过期，同时核对其他层的过期时间是否一致。前提是你能确认该版本是当前正确版本，且旧版本不会造成事实性错误。
- 改写：当分歧来自缓存键过粗或过细，例如把带查询串的请求与不带查询串的请求混在同一键下，应改写缓存键或Vary规则，让不同版本各归其位。前提是你能列出所有会改变响应的请求维度。
- 退出：当某一层无法提供可核对的缓存键或过期证据，且持续返回与源站冲突的版本时，让该层退出缓存或缩短其TTL，先把一致性恢复到可观测状态。前提是你能承担回源压力上升的代价。
三种取舍不必同时使用。若分歧只发生在单个边缘节点，保留其他层、只让该节点退出缓存，往往比全局清空更可控。
把分歧转成可核对的项目清单
要让多个角色对同一事实达成一致，需要把“我这边是404”转成可核对的条目。至少包括：请求的完整URL、请求头中的关键维度、命中的缓存层、该层返回的状态码与响应体摘要、该层的缓存键与TTL、回源状态码。缺少其中任何一项，分歧都会被归因于观测差异而非真实不一致。
一个实际动作是：在边缘层临时关闭对问题路径的缓存，只保留回源直连，然后分别从边缘和源站发起相同请求，比对状态码和响应体哈希。若两者一致，说明问题在缓存层；若仍不一致，说明问题在源站或更上层。这个动作的结果直接决定下一步是查缓存键还是查源站逻辑。
需要说明的是，抓取量或请求量归零不能单独证明处理正确，因为流量下降也可能来自客户端重试停止、监控采样变化或上游路由调整。要确认一致性恢复，应比对状态码分布和响应体哈希，而不是只看请求数。
容易被忽略的边界：缓存之外还有配置层
有些“多层缓存不一致”实际来自配置层。例如 robots.txt 的抓取限制只约束爬虫行为，不等于可靠的索引移除；站点地图不保证收录；HTTPS 不保证安全无漏洞或排名。这些规则与缓存版本无关，但在排查时容易被混为一谈。若分歧只在爬虫请求中出现、普通用户请求正常，应先检查是否命中了不同的缓存键或不同的回源规则，而不是先改 robots.txt。
不同搜索引擎对缓存相关指令的支持情况须分别核查。把某一家的行为当作通用结论，会让后续判断建立在错误前提上。定位一致性问题的核心始终是：每一层返回了什么、依据什么键返回、过期时间是多少，以及这些证据能否被其他角色独立复核。只有把分歧落到可核对的条目上，保留、改写或退出的选择才有依据。
