域名与空间，同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /724483842636.html
📄
域名与空间，同一地址因设备或登录状态返回不同内容怎样对照
先别急着改站。把同一 URL 在“未登录、桌面浏览器”“未登录、移动浏览器”“已登录、目标账号”三组条件下各取一份原始响应，对照的是响应本身，而不是肉眼看到的页面。若三份响应正文一致，差异来自渲染或缓存；若正文不同，才需要判断是空间侧按条件分流，还是域名侧解析到了不同源站。多数情况下，先保留证据再决定改写或退出，比直接动配置更省事。
先固定对照变量，避免把渲染差异当成内容差异
设备和登录状态会同时改变两件事：请求头与所命中的服务端逻辑。要分开它们，取响应时至少固定以下变量：
- 同一完整 URL，含协议与结尾斜杠写法一致；
- 同一时间窗内连续取，避免发布或缓存刷新夹在中间；
- 记录状态码、
Content-Length、Vary、Cache-Control和响应正文前若干行； - 登录态那一份，明确用的是哪个账号、哪种角色。
如果未登录桌面与未登录移动的正文一致，只是排版不同，那属于前端适配，不需要按内容分流处理。若正文本身不同，才进入下一步判断。
用响应头区分三种常见成因
同一地址返回不同内容，常见成因有三类，它们的证据特征不一样：
- 服务端按条件输出：响应头里常出现
Vary: User-Agent或Vary: Cookie，且不同条件下正文结构不同。这是空间侧程序逻辑，属于有意分流。 - 缓存分层：同一条件重复请求，正文时好时坏，或
Age、命中标记变化。此时差异不是内容策略，而是缓存副本不一致。 - 解析到不同源：同一域名在不同网络或设备下解析结果不同，导致请求落到了不同空间。特征是响应头里的服务标识、证书信息或默认页风格成组变化。
把这三类分开，后面的取舍才有依据。把缓存问题当成内容分流去改程序，或把解析问题当成缓存去清缓存，都会白费一轮。
保留、改写还是退出：三种取舍的适用前提
保留适用于差异是有意为之且可解释的情况。例如登录后展示账户内容、未登录展示公开页，这是正常的产品行为。前提是：未登录版本本身可被抓取、可被索引，且不依赖登录才能看到核心信息。如果未登录版本是空壳，保留分流就等于让外部只能看到空壳。
改写适用于差异来自实现方式而非产品意图的情况。典型是空间侧误把爬虫请求当成异常流量返回了不同页面，或缓存规则把移动端和桌面端混在一起。此时动作是收敛输出：让同一 URL 对未登录的桌面与移动返回同一份正文，差异只留给 CSS 和交互。改完后重新取三组响应，确认正文一致，再决定是否需要进一步处理。
退出适用于差异无法在现有空间内稳定收敛的情况。例如同一域名被解析到多个不受同一套配置控制的空间，且无法统一响应逻辑。此时更现实的做法是把该地址收敛到单一源，或改用能明确控制输出的路径，而不是继续在两边打补丁。
三种取舍不是必须全选。多数站点只需要在“保留”和“改写”之间做一次判断，退出是前两者都不可行时的兜底。
一个假设例子：三组响应如何指向不同结论
假设某地址在未登录桌面下返回完整正文，未登录移动下返回一段提示，登录后返回完整正文。三份响应里，移动那份的响应头带有 Vary: User-Agent，且正文长度明显更短。这个组合更支持“服务端按 UA 分流”，而不是缓存或解析问题，因为同一条件重复请求结果稳定。
反过来，如果未登录桌面下两次请求正文不同，一次完整一次残缺，且残缺那份带有较长的 Age，那更支持缓存副本不一致。此时先处理缓存，而不是改程序。
这个例子的数字只用于说明比较方法，不代表任何真实站点的表现。
对照之后，哪些动作会改变下一步
取完三组响应后，至少做一件事：把三份响应正文和关键响应头存档，标注取数时间与条件。这个动作的结果直接决定下一步——
- 若正文一致，只需检查渲染与缓存，不必动空间配置；
- 若正文不同且带
Vary，先确认未登录版本是否包含核心信息，再决定保留还是改写； - 若正文不同且无
Vary、重复请求不稳定，优先排查缓存与解析，而不是内容策略。
另外要分清抓取限制与索引结果：robots.txt 里的限制只约束抓取，不等于把已收录地址移除；站点地图提交也不保证收录。对照响应的目的是判断“外部实际能看到什么”，而不是替代这些机制。把响应证据留全，再决定保留、改写还是退出，才不会在下一轮改动里反复推翻自己。
