二级域名设置：怎样排除缓存造成的假象
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6228dc67cf61.html
📄
二级域名设置：怎样排除缓存造成的假象
二级域名设置后看到旧页面、旧标题或旧内容，先不要认定设置失败。缓存可能存在于浏览器、DNS、CDN、反向代理或搜索引擎快照等多个环节。排除假象的核心方法是：用不依赖本地缓存的请求直接访问源站，再逐层对比响应头与内容，确认哪一层还在返回旧数据。
先分清“缓存假象”与“真实未生效”
缓存假象的特征是：不同网络、不同设备、不同工具看到的结果不一致；过一段时间或换一个查询节点后结果改变。真实未生效的特征是：源站本身返回的仍是旧内容或错误状态，无论从哪里访问都一样。
- 用手机流量和办公室宽带分别访问同一二级域名，结果不同，偏向缓存问题。
- 用命令行工具直接请求源站 IP 并指定 Host，返回新内容，说明源站已更新，问题在中间层。
- 多次刷新都是同一旧内容，且换网络也不变，要检查源站配置和解析记录，而不是继续清缓存。
假设例子：二级域名已指向新目录，浏览器仍显示旧首页
假设你有一个主站 example.com，新增二级域名 blog.example.com，并把它的根目录指向一个新部署的博客程序。你在浏览器打开 blog.example.com，看到的却是主站旧首页。这个现象至少有三种解释：DNS 解析未生效、Web 服务器虚拟主机配置未匹配、中间缓存返回了旧响应。不能直接断定是缓存，也不能直接断定是配置错误。
可以按下面步骤排查：
- 在命令行执行
dig blog.example.com或nslookup blog.example.com，确认解析结果是否指向你预期的服务器 IP。如果解析还是旧 IP，问题在 DNS 缓存或解析记录，不在网页缓存。 - 直接请求源站 IP，并带上二级域名的 Host 头，例如
curl -H "Host: blog.example.com" http://你的源站IP/。如果返回新博客首页，说明源站虚拟主机已生效。 - 用
curl -I https://blog.example.com/查看响应头，重点看Age、Cache-Control、X-Cache、CF-Cache-Status等字段。出现较大的Age或命中缓存标识，说明中间层可能返回了旧内容。 - 在 URL 后加一个临时查询参数，例如
https://blog.example.com/?test=20240101，再次访问。如果带参数能看到新内容，而不带参数仍是旧内容，基本可以判断是缓存层按 URL 缓存了旧响应。 - 检查 CDN 或反向代理的缓存规则，确认二级域名的缓存键、缓存过期时间和回源规则是否与主站混用。
常见错误是只清理浏览器缓存，却忽略 CDN 和反向代理；或者只刷新 CDN，却没有检查 DNS 的 TTL 是否过长。另一个错误是把 robots.txt 的抓取限制当成索引移除手段，这并不会让已经收录的旧页面立即消失，也不能解决缓存层返回旧内容的问题。
逐层检查清单
- 浏览器层：用无痕窗口或另一款浏览器访问，排除本地缓存和本地 Cookie 干扰。
- DNS 层：查询权威 DNS 与本地递归 DNS 的结果是否一致，注意 TTL 到期前旧记录仍可能被返回。
- CDN 或代理层：查看响应头中的缓存命中标识，必要时对指定 URL 执行刷新或等待缓存过期。
- 源站层：直接请求源站 IP 加 Host 头，确认 Web 服务器返回的是新内容。
- 搜索引擎层：搜索结果的快照或标题可能滞后，这不等于二级域名设置失败，应分别核查抓取、索引和缓存状态。
判断结果与适用条件
如果源站直接请求返回新内容，而通过二级域名访问返回旧内容，并且响应头显示缓存命中，那么可以把问题定位在中间缓存层。此时应调整缓存规则或刷新缓存，而不是反复修改二级域名解析。
如果源站直接请求也返回旧内容，那么缓存不是主要原因，应检查虚拟主机配置、目录指向、程序路由或重写规则。如果 DNS 查询结果与预期不符，应先处理解析记录和 TTL，而不是处理网页缓存。
这套方法适用于已有页面或项目在二级域名设置后出现内容不一致的场景。它不保证搜索引擎立即更新索引，站点地图提交也不保证收录；HTTPS 只表示连接加密，不保证页面无漏洞或排名提升。不同搜索引擎对二级域名的抓取和索引支持情况需要分别核查。
下一步：选定一个受影响的二级域名 URL，按“DNS 查询 → 源站直连 → 响应头检查 → 带参数访问”的顺序做一次记录，把每层返回的状态码和内容摘要写下来，再决定是刷新缓存还是修改源站配置。
