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

特殊后缀域名：怎样排除缓存造成的假象

排查特殊后缀域名时，缓存假象的典型表现是：同一URL在不同人、不同网络、不同工具下返回不同内容，或修改后仍看到旧页面。要排除它，核心原则是先固定观察条件，再对比来源，最后回到源站验证。下面是一份可执行清单，每项都说明查什么、怎么查、结果说明什么。

先确认你看到的到底是哪一层缓存

特殊后缀域名常见的缓存层包括：浏览器本地缓存、系统或公司网络中间缓存、CDN边缘缓存、源站页面缓存与对象缓存。排查时不要一上来就清缓存，而要先判断“旧内容”来自哪一层。

• 查什么：响应头中的缓存相关字段，例如 Cache-Control、Age、ETag、Last-Modified、X-Cache、CF-Cache-Status（若使用对应CDN）。
• 怎么查：用命令行请求同一URL，分别带与不带缓存绕过参数，观察响应头差异。示例：curl -I https://example.test/page 与 curl -I "https://example.test/page?cb=20240101"。这里 example.test 是假设域名，仅作演示。
• 结果说明什么：若带随机参数返回新内容、不带参数返回旧内容，说明中间层或CDN缓存了旧响应；若两者都旧，问题更可能在源站或页面缓存。

用多网络、多身份交叉验证，而不是只刷新一次

多人协作时，最容易返工的原因是“我这边好了”被当成“已经好了”。需要把观察条件写清楚并交叉验证。

1. 查什么：同一URL在无痕窗口、已登录窗口、不同网络（例如公司网络与手机热点）、不同地区节点下的返回内容。
2. 怎么查：记录每次请求的时间、网络、是否登录、返回的状态码和关键内容片段。不要只截图页面外观，要保留响应头或工具输出。
3. 结果说明什么：若只有某一网络或某一身份看到旧内容，优先怀疑该路径上的缓存或权限差异；若所有条件都看到旧内容，则回到源站和发布流程检查。

绕过缓存验证源站，但不要混淆“绕过”与“修复”

加随机查询参数、使用开发者工具禁用缓存、切换无痕模式，都只是绕过缓存来观察源站，不等于已经修复了缓存问题。特殊后缀域名还可能因为解析、重定向或路径规则导致不同入口命中不同缓存键。

• 查什么：源站直接返回的内容是否已经是新版本；重定向链是否一致；带与不带 www、带与不带结尾斜杠是否落到同一资源。
• 怎么查：用 curl -IL 跟踪重定向，确认每一跳的状态码和最终URL；再对比最终URL的响应体关键字段。
• 结果说明什么：若源站已是新内容而外部仍是旧内容，问题在缓存刷新或缓存键；若源站仍是旧内容，问题在发布、构建或页面缓存，不应继续清CDN。

把“抓取限制”和“索引移除”分开看

排查缓存假象时，常有人把 robots.txt、站点地图、HTTPS 当成万能解释。需要明确：robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 不保证安全无漏洞或排名。它们不能直接证明你看到的旧内容就是缓存造成。

• 查什么：当前URL是否被 robots.txt 允许抓取；页面是否返回 noindex；站点地图是否包含该URL。
• 怎么查：直接请求 /robots.txt 核对规则；查看页面响应头或HTML中的 <meta name="robots">；在站点地图文件中搜索该URL。
• 结果说明什么：这些检查只能说明抓取和索引层面的状态，不能替代对缓存层的判断。若它们与缓存现象同时存在，应分别记录、分别验证。

交付时写清“已排除项”和“待确认项”

为了减少返工，交付记录不要只写“已刷新缓存”。建议按下面格式留痕：

• 已排除：浏览器本地缓存（无痕窗口返回新内容）、公司网络缓存（手机热点返回新内容）。
• 待确认：CDN边缘节点是否全部刷新，需在不同地区节点复测。
• 判断依据：响应头中的 Age 是否下降、X-Cache 是否从命中变为未命中、源站响应体是否已更新。
• 适用条件：以上方法适用于你能控制源站和缓存配置的域名；若域名后缀特殊导致部分工具不支持，应改用通用HTTP请求工具核对，而不是依赖单一平台界面。

下一步：选一个仍显示旧内容的URL，按“响应头—多网络—源站—抓取索引”的顺序各记录一次结果，再把无法复现的条件单独列出，交给协作方复测。