如何选择域名：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7cb0858d972.html
📄
如何选择域名：多层缓存返回不同版本时怎样定位一致性问题
先给有条件的结论：如果同一域名在不同网络、不同设备或不同登录状态下返回的页面版本不一致，优先怀疑“缓存键设计不统一”，而不是先改DNS或换域名。只有当所有缓存层都按同一套键（主机名、路径、查询串、Cookie、设备类型）存储，且回源结果本身稳定时，才可以把问题归到域名选择或解析配置上。否则，换域名只会把不一致带到新名字上。
先确认“不同版本”是缓存差异，还是回源内容真的不同
定位的第一步不是清缓存，而是固定一个可复现的请求。用同一路径、同一查询串、同一User-Agent，分别从本机、办公网和一台外部服务器发起请求，记录响应中的 Age、Cache-Control、ETag 和实际正文片段。如果三处正文不同但 ETag 相同，说明中间层改写了内容却没更新校验标识；如果 ETag 不同，则更可能是回源生成了不同版本。
一个可区分的证据组合：
- 外部服务器拿到旧版、本机拿到新版，且旧版响应带较大的
Age——偏向边缘节点或CDN缓存未刷新。 - 所有位置都拿到旧版，但直接请求源站IP拿到新版——偏向中间层缓存键忽略了某个维度。
- 登录后新版、未登录旧版——偏向缓存键没有把Cookie或会话状态纳入区分。
- 带与不带末尾斜杠结果不同——偏向路径规范化规则在各层不一致。
这里要提醒一个常见误判：抓取量或请求量突然归零，并不能单独证明缓存处理正确。它也可能是日志采样变化、爬虫策略调整或监控口径改变造成的。把归零当作“问题已解决”的证据，容易漏掉仍在返回旧版的边缘节点。
多层缓存下，一致性问题的根因通常在“键”而不在“域”
典型链路是：浏览器缓存 → CDN边缘 → 反向代理 → 应用层缓存 → 源站。每一层都有自己的键。只要其中一层用了不同的键，同一域名就会返回不同版本。常见的键差异包括：
- 是否把
Host头完整纳入键。带www与不带www若都解析到同一服务，但缓存层按不同主机名分别存储，就会出现两个版本。 - 是否区分查询串顺序。
?a=1&b=2与?b=2&a=1在部分缓存中被视为不同资源。 - 是否把移动端与桌面端分开存储，但回源时又用了同一份内容。
- 反向代理与应用层对
Vary头的处理不一致。
假设一个场景：某站点同时保留旧域名和新域名，旧域名仍被部分合作方引用。运营希望旧域名继续可用，但只保留少数几个仍然有价值的页面。此时如果两个域名共用同一套缓存，而缓存键只按路径不按主机名区分，访问旧域名某个路径可能返回新域名下的同名内容。这不是域名选错，而是缓存键少了一个维度。动作是：在反向代理配置中把主机名纳入缓存键，然后重新请求旧域名路径，观察返回的 ETag 是否与源站一致。如果一致，下一步才是决定旧域名哪些路径继续保留、哪些返回跳转或410。
让结论失效的反例：回源本身就不稳定
上面“先查缓存键”的结论有一个明确的反例：如果源站在短时间内对同一请求返回不同内容，比如应用层做了灰度发布、A/B测试或按时间戳生成页面，那么无论缓存键多统一，各层仍会看到不同版本。判断方法是绕过所有缓存直接请求源站，连续多次请求同一路径，比较正文哈希。如果源站自身就不一致，缓存只是放大了差异，改缓存键不会解决问题。
另一个会使结论失效的条件是：不同搜索引擎或平台对同一域名的处理方式不同。某平台可能仍保留旧域名的索引，另一平台已切换到新域名。这时“版本不一致”可能来自平台侧缓存，而不是你自己的缓存层。需要分别核查各平台的抓取与展示情况，不能用一个平台的表现推断全部。
下一步动作：先固定键，再决定域名的去留
在确认回源稳定后，按这个顺序操作：
- 列出当前所有缓存层及其键的构成，标出哪一层缺少主机名、Cookie或设备维度。
- 对缺少的维度补齐配置，然后用同一路径在旧域名和新域名下分别请求，比较
ETag与正文片段。 - 如果补齐后旧域名返回的仍是新域名内容，检查是否有重写规则在回源前改写了
Host。 - 只有在缓存键统一且回源稳定后，才评估旧域名是否继续保留、哪些路径保留、哪些做跳转或移除。
这个顺序的意义在于：域名选择是一个长期决策，而缓存键不一致是一个可以立即修复的配置问题。先修键，能让你看清旧域名上到底还有哪些内容真正独立存在，再决定保留哪些部分。否则你会在一个被缓存污染的结果上做域名取舍，后续每一步都可能被同一个旧版本反复干扰。
