主机域名选择：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7f84c48ad6d2.html
📄
主机域名选择：多层缓存返回不同版本时怎样定位一致性问题
当你把旧系统的一部分内容迁移到新主机或新域名后，发现同一页面在不同网络、不同入口下返回了不同版本，先不要急着改代码。多数情况下，问题出在多层缓存各自保存了不同时间点的副本，而不是源站内容本身出错。定位的起点是：把“用户看到的版本”和“源站真实输出”分开验证，再逐层向上游排查。
先确认源站输出是否唯一
在动任何缓存配置之前，先绕过所有中间层，直接向源站请求目标资源。假设你的主机域名选择方案是保留旧域名做跳转、新域名承载内容，那么源站请求应带上明确的 Host 头，并关闭本地浏览器缓存。
- 用命令行工具直接请求源站 IP，记录返回的状态码、关键响应头和正文摘要。
- 连续请求两次，间隔几秒，观察正文摘要是否变化。若变化，问题在源站或应用层，缓存只是放大器。
- 若源站输出稳定，再逐层加上 CDN、反向代理、页面缓存插件，每加一层重复一次请求。
这一步的实际动作是建立一条“请求路径链”。每多一层，你就多一个可对比的样本。结果会直接决定下一步：源站不稳就先修应用，源站稳定才继续查缓存。
区分缓存层各自保存了什么
多层缓存返回不同版本，常见原因是各层的过期时间、缓存键和清除机制不一致。你需要分别确认每一层是否缓存了目标资源，以及它的缓存键包含哪些维度。
- 浏览器缓存：看响应头中的缓存指令和实际命中的本地副本。清除本地缓存后再请求，观察版本是否变化。
- CDN 或边缘缓存：用带唯一查询参数的请求对比不带参数的请求。若带参数返回新版本、不带参数返回旧版本，说明缓存键没有包含你预期的维度。
- 反向代理或应用层缓存：检查是否按 URL、Cookie 或用户代理分别存储。不同入口返回不同版本，往往是因为某一层把登录态或设备类型纳入了缓存键。
- 数据库或对象存储缓存：确认是否存在读写分离或副本延迟。旧版本可能来自尚未同步的只读副本。
这里的关键不是记住所有缓存类型，而是对每一层问两个问题：它缓存了什么，它凭什么判断这是同一个资源。两个答案不一致，就会产生版本分裂。
旧内容退出时保留部分价值的具体做法
假设你正在处理一批旧页面：一部分要下线，一部分仍有访问价值。多层缓存不一致会让“下线”变得不可靠，因为旧版本可能仍被某一层返回。
- 对确定要退出的页面，先确认源站返回明确的移除状态，再逐层清除缓存。只清一层，其他层仍可能继续返回旧内容。
- 对仍有价值的页面，保留其源站输出，但统一各层缓存键和过期策略。让所有层对“这是同一个资源”达成一致。
- 对需要跳转的旧地址，确认跳转发生在哪一层。若跳转在边缘层完成，源站可能从未收到请求，排查时要单独验证边缘规则。
一个可执行的判断是：如果同一 URL 在清除所有缓存后仍返回旧版本，问题不在缓存，而在源站或数据副本。这时继续清缓存只会浪费时间，应转向检查应用输出和数据同步。
用可复查的证据代替反复刷新
反复刷新页面得到的结论通常不可复查，因为每次请求可能命中不同层。更可靠的做法是固定请求条件并记录结果。
- 记录每次请求的时间、目标地址、返回状态码、关键响应头和正文摘要。
- 对同一资源至少取三组样本：直连源站、经过一层缓存、经过全部缓存。
- 比较三组样本的差异出现在哪一层，而不是只比较最终页面。
如果三组样本中只有一组不同，问题范围就缩小到那一层。如果三组都不同，说明源站输出本身不稳定，缓存只是把差异暴露出来。这个结果会影响下一步：是调整缓存策略，还是先修复源站的一致性。
哪些现象不能单独作为结论
请求量下降、抓取量变化或某个入口暂时返回新版本，都不能单独证明缓存问题已经解决。它们可能有其他解释，比如网络路径变化、请求头差异或副本同步延迟。把一次观察当作结论，容易在下一层缓存再次返回旧版本时失去方向。
另外，用抓取限制文件阻止访问，并不等于可靠地移除已缓存或已索引的内容；站点地图的存在也不保证各层会按你预期的时间更新。这些手段可以作为辅助，但不能替代逐层验证。只有当你能够稳定复现“源站输出一致、各层缓存键一致、清除后不再返回旧版本”时，才可以把一致性问题视为已定位并处理完毕。
