域名选择技巧：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /82ba0e682ba4.html
📄
域名选择技巧：多层缓存返回不同版本时怎样定位一致性问题
先给有条件的结论：当同一域名在不同网络、不同地区或不同设备上返回的页面版本不一致时，优先怀疑缓存链路而非源站，但前提是你已经确认源站本身只输出一个版本。如果源站对同一路径按请求头、Cookie 或时间返回不同内容，那么缓存只是把这种差异放大，定位方向要立刻转向源站逻辑。判断顺序应是先固定源站，再逐层向外排查。
先确认源站是否只有一个版本
把缓存全部绕过，直接请求源站，并且用两组不同的请求头分别测试：一组带常见的移动端 User-Agent，另一组带桌面端 User-Agent；一组带 Cookie，另一组不带。如果这两组结果就已经不同，说明一致性问题的根在源站，缓存层只是忠实保存了不同版本。
这一步的实际动作是记录每个版本的响应头，重点看 Vary、Cache-Control、ETag、Last-Modified。如果 Vary 里包含 User-Agent 或 Cookie，而缓存节点没有正确遵循，就会出现“同一 URL 不同人看到不同内容”。此时下一步不是清缓存，而是决定这个差异是否应该存在：如果业务上确实要按设备分流，就要让缓存键与 Vary 一致；如果不该分流，就先修源站。
用响应头区分是缓存还是源站问题
逐层请求时，观察响应头里的缓存命中标识、Age 和 X-Cache 一类字段（具体字段名取决于你的服务商，需自行核对）。可区分的原因大致有三类：
- 源站多版本：绕过所有缓存后仍不一致，
ETag或正文哈希不同。 - 中间缓存键错误：源站一致，但带不同请求头时缓存节点返回了别的版本，
Age明显偏大。 - 客户端或本地缓存：换网络、换设备后差异消失，说明问题在浏览器或本地代理。
这三类证据指向的动作不同：第一类改源站，第二类改缓存键或 Vary，第三类只需调整本地缓存策略。把三者混在一起清缓存，往往清完短时间正常、之后又复现。
一个会推翻结论的反例
前面的结论建立在“源站只输出一个版本”之上。反例是：源站按地理位置返回不同币种或不同语言，且没有在缓存键里体现地区。这时你在 A 地看到的价格和 B 地不同，并不是缓存坏了，而是缓存把 A 地的响应发给了 B 地用户。此时正确动作是让缓存键包含地区维度，而不是强行统一源站输出。若忽略这个前提，直接判定“缓存不一致”，就会改错地方。
同理，如果站点用 robots.txt 限制抓取，或依赖站点地图期待收录，这些都不构成版本一致性的证据；抓取限制不等于索引移除，站点地图也不保证收录。它们与缓存版本问题是两条线，不要混为一谈。
下一步动作与验证方式
假设一个短例子：某路径在桌面端返回 A 版、移动端返回 B 版，源站测试也如此。先假设这是预期分流，那么动作是检查缓存键是否包含设备维度，验证方法是分别用两种 User-Agent 请求并确认各自稳定命中对应版本。如果源站测试其实只有一个版本，那么动作转为检查缓存节点的 Vary 处理，验证方法是连续多次请求并对比 ETag 与正文哈希是否收敛到同一值。
无论走哪条路，先固定源站输出、再逐层加回缓存，每加一层记录一次结果，这样差异出现在哪一层就一目了然。只有把“源站是否单版本”这个前提确认清楚，后续的缓存排查才有意义。
