域名历史：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b71d8b664896.html
📄
域名历史：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：这不是“域名历史”本身在变，而是同一地址在不同设备、登录态或缓存层前被分流到了不同版本。对照时不要继续换浏览器刷新，而要先固定一个可复现的请求条件，再逐项替换变量。能区分“服务端分流”和“客户端缓存”的关键证据，是响应头与页面正文是否同时变化。
先固定一个可复现的请求条件
你需要的不是“多试几次”，而是一份最小对照记录。假设同一地址在手机未登录时看到旧版，在桌面已登录时看到新版，那么至少记录四组组合：桌面未登录、桌面已登录、手机未登录、手机已登录。每组记录状态码、Content-Length、Vary、Cache-Control，以及正文中一个稳定的文本片段。这个动作的结果会直接决定下一步：如果响应头不同，问题在服务端或中间层；如果响应头相同而正文不同，问题更可能在客户端渲染或缓存。
两种解释：服务端分流与客户端缓存
解释一：服务端按设备、登录态或地域返回了不同版本。常见触发条件是 UA 判断、Cookie 判断、CDN 边缘规则或 A/B 测试分流。此时同一 URL 会返回不同 HTML，Vary 头可能包含 User-Agent 或 Cookie。如果 Vary 缺失，中间缓存就可能把某个版本错误地交给另一类访问者，造成“同一地址内容不同”的错觉。
解释二：服务端返回相同内容，客户端或中间层改变了呈现。登录态可能触发前端脚本替换模块，设备差异可能触发响应式隐藏，浏览器扩展或本地缓存可能保留旧资源。此时原始 HTML 相同，差异出现在脚本执行之后。要区分这两种解释，不能只看最终截图，必须看原始响应。
能区分解释的证据：响应头与正文片段
用命令行请求并保存原始响应，比截图更可靠。例如：
curl -I只看响应头，比较状态码、Vary、Cache-Control、Set-Cookie。curl带不同 UA 或 Cookie 请求正文，比较同一文本片段是否存在。- 在浏览器开发者工具的 Network 面板中禁用缓存，分别记录文档请求的响应头与响应体。
如果带 Cookie 的请求返回了不同的 Vary 或不同的正文片段，而清空 Cookie 后恢复一致，那么服务端分流更成立。如果响应头与正文完全一致，但页面在登录后仍然不同，那么差异来自前端脚本或本地存储，应继续检查 localStorage、sessionStorage 和脚本条件分支。
一个假设例子：怎样把对照结果转成下一步
假设同一地址在桌面未登录时返回旧标题，在桌面已登录时返回新标题，手机未登录时又返回旧标题。先记录三组原始响应。若已登录组的 Vary 含 Cookie，而未登录组不含，则说明中间层可能按 Cookie 分流。下一步不是改页面文案，而是检查 CDN 或反向代理的缓存键是否包含 Cookie，以及是否对未登录用户错误命中了已登录版本。若三组响应头完全相同、正文片段也相同，则下一步应转向前端脚本和本地缓存，而不是继续调整服务端规则。
还要注意一个容易忽略的条件：robots.txt 的抓取限制不等于索引移除，站点地图也不保证收录。因此，即使你发现某个版本没有被抓取，也不能单独用它证明“旧版本已经处理正确”。请求量或抓取量归零，也可能由屏蔽、超时、路由错误或统计口径变化解释，需要与响应头证据一起看。
把对照做成可交接的记录
最终要留下的是可复现的最小记录：一组请求条件、对应的响应头、正文片段是否一致，以及你据此排除了解释一还是解释二。这样交接时，对方不需要重复猜测设备或登录态，只需按记录替换一个变量，就能判断问题落在服务端分流、中间缓存还是客户端渲染。对照的目的不是证明谁对，而是让下一个动作有明确依据。
