📍 WDQWDWQD987AAAAA:216.73.216.28
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1373ce280eb4.html
📄

网站首选域名设置 - 怎样排除缓存造成的假象

判断“首选域名设置没生效”时，先别急着改配置。最常见的情况是：设置本身已经生效，但你看到的仍是缓存返回的旧页面。排除缓存假象的可靠方法是同时对比三样东西——浏览器实际收到的响应头、跳转链路、以及不同网络环境下的结果。三者一致才说明设置真的生效；只有浏览器页面变了或没变，都不足以作为判断依据。

先分清是哪一层缓存

“缓存”在首选域名这个问题上至少涉及四层，排查时要逐层排除，不能混在一起下结论。

• 浏览器缓存：保存了旧的 HTML、旧的 301 记录。现象是同一台电脑反复看到旧域名，换设备就正常。
• 中间缓存与 CDN：CDN 节点缓存了旧的重定向响应或旧页面。现象是部分地区正常、部分地区异常。
• DNS 缓存：本机或本地递归解析器仍返回旧 IP。现象是解析结果与权威记录不一致。
• 服务端缓存：反向代理、页面缓存插件返回了旧的规范化链接。现象是响应头正常但页面里的链接仍是旧域名。

多人协作时，最容易返工的原因就是每个人看到的层不同，却都声称“我这边是对的”。交付前必须约定统一口径：以响应头和跳转链路为准，不以肉眼看到的页面为准。

用响应头判断，而不是用眼睛看

首选域名设置的核心表现是：访问非首选域名时返回 301 或 308，并指向首选域名。判断它是否生效，看的是响应状态码和 Location 头，而不是地址栏最终停在哪里。

可以执行的检查步骤：

1. 用命令行请求非首选域名，只看响应头，不跟随跳转：curl -I http://example.com（把域名替换成你自己的）。
2. 观察返回的状态码是否为 301 或 308，以及 Location 是否指向首选域名。
3. 再用 curl -I https://example.com 重复一次，确认 HTTP 和 HTTPS 两个入口都指向同一目标。
4. 对首选域名本身也请求一次，确认它返回 200 而不是又跳回去，避免出现循环重定向。

如果响应头符合预期，但浏览器里仍看到旧域名，问题基本可以定位在浏览器缓存或本地 DNS，而不是服务器设置。反之，如果响应头本身就不对，那和缓存无关，应该去检查服务器配置或 CDN 规则。

换环境复查，避免被单点结果误导

同一台设备、同一个网络只能证明一个点。要排除缓存假象，至少换两个变量复查：

• 换网络：用手机流量代替公司 Wi-Fi，绕开本地 DNS 和代理缓存。
• 换设备或换浏览器配置文件：绕开浏览器缓存和已保存的 HSTS 状态。
• 加随机查询参数：例如 ?v=20240101，用于判断页面级缓存是否在起作用。注意这只对页面缓存有效，对 301 跳转缓存往往无效。
• 查看 CDN 或反向代理的缓存命中状态：如果响应头里出现缓存命中标识，说明你拿到的是节点缓存，需要先刷新再判断。

判断标准很直接：如果换网络、换设备后结果一致，说明是真实配置；如果只在某一台设备或某一个网络下异常，优先怀疑缓存。这里要注意，301 被浏览器长期缓存是常见现象，清理浏览器缓存或用无痕窗口往往比反复改配置更有效。

多人协作时的交付与防返工

首选域名设置属于基础设施改动，一旦多人同时操作，很容易出现“改了一半、缓存没刷、结论互相矛盾”的局面。建议按下面的顺序交付，减少返工：

1. 先确认服务器和 CDN 配置已全部改完，再统一刷新缓存，不要边改边测。
2. 把 curl -I 的响应头结果贴进交付记录，作为唯一判断依据，而不是截图浏览器地址栏。
3. 明确写出复查时间点和复查人，避免不同人在不同缓存状态下得出相反结论。
4. 如果同时涉及 robots.txt 或站点地图，记住它们和首选域名是两回事：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，不能用来验证首选域名是否生效。

下一步

现在就可以做一件事：对非首选域名的 HTTP 和 HTTPS 各执行一次 curl -I，把状态码和 Location 记下来。如果这两条都正确指向首选域名，就不要再纠结浏览器里看到什么，直接去清理本地缓存和 DNS；如果响应头不对，就先修配置，缓存问题留到配置确认之后再处理。