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

网站首选域名设置多层缓存返回不同版本时怎样定位一致性问题

先判断不一致发生在哪个缓存层，而不是先清缓存。多层缓存同时存在时，同一URL可能被CDN、反向代理、应用层缓存分别保存，首选域名设置只是决定规范入口，并不能让各层内容自动同步。定位顺序应是：确认各层缓存键是否包含域名与协议、确认回源时首选域名是否被正确重写、再确认失效指令是否真正到达每一层。若跳过前两步直接刷新，往往只能暂时掩盖问题。

先分清两种前提：缓存键是否包含首选域名

这是决定排查方向的第一组条件。如果各层缓存键把主机名纳入计算，那么 https://example.com 与 https://www.example.com 会各自形成独立缓存条目，即使首选域名设置为其中一方，另一方的旧缓存仍可能继续返回。此时不一致通常表现为：带www的版本是旧内容，裸域是新的，或反过来。处理动作是逐层核对缓存键配置，把非首选域名在边缘层做301跳转到首选域名，让后续请求只落到一套缓存键上。跳转生效后，再用同一路径分别请求两种主机名，观察是否都返回首选域名的内容，这一步决定你接下来是继续查回源还是查失效。

如果缓存键不包含主机名，问题会更隐蔽：不同域名的请求可能命中同一条缓存记录，谁先写入谁生效。这时不一致表现为随机性——同一URL多次请求返回不同版本，且与请求域名没有稳定对应关系。此时要优先检查反向代理和CDN是否开启了忽略主机名的缓存合并，并确认应用层是否根据 Host 头生成不同内容。动作是把缓存键恢复为包含主机名，再观察随机性是否消失；若消失，说明此前是键设计导致的串缓存，而非首选域名设置本身出错。

用回源请求验证首选域名是否被正确重写

边缘层命中缓存时看不到真实回源行为，所以要在缓存未命中或强制回源的条件下观察。假设某站点首选域名设为裸域，边缘层收到www请求后应301到裸域，再由裸域回源。如果边缘层只是把www请求直接回源但没有重写 Host，应用层可能按www生成页面，而页面内的规范链接、资源地址又指向裸域，于是同一页面出现两套地址。验证动作是构造一个带随机查询参数的URL，让缓存必然未命中，分别用两种主机名请求，记录回源请求里的 Host 头和响应里的规范链接。若回源 Host 与首选域名不一致，下一步应修正边缘层的回源重写规则，而不是去调应用层缓存时间。

这里有一个容易误判的现象：某些统计里非首选域名的请求量降到接近零，并不等于一致性问题已解决。它也可能只是监控探针改了请求地址，或边缘层把非首选域名直接拦截返回空响应。要区分这两种解释，需要同时看响应状态码和响应体长度，而不是只看请求计数。

确认失效指令是否到达每一层

当缓存键和回源都正确，不一致仍可能出现，原因是内容更新后只有部分层收到失效通知。典型表现是：应用层已更新，反向代理仍是旧版本，CDN边缘又是另一个时间点的版本。排查动作是给同一次内容变更打上可识别的标记，例如在响应头或页面注释里写入一个假设的版本串，然后按“应用层直连→反向代理→CDN边缘”的顺序逐层请求，记录每层返回的版本串。哪一层版本串落后，问题就锁定在该层与其上游之间的失效链路。

需要说明的是，失效指令发出不等于立即全局生效，边缘节点数量、传播延迟都会影响观察结果。如果多次请求中旧版本比例持续下降，通常属于传播过程；如果比例长期不变，才更可能是失效配置遗漏了某一层。这个判断依据能帮你决定是继续等待还是立即修配置。

例外：首选域名变更期间不要用同一套判断

如果当前正处于首选域名从A切换到B的过渡期，上述“逐层对齐”的结论要临时调整。切换期内允许两层返回不同版本，因为旧域名的缓存需要自然过期，此时强行让所有层立即一致，可能造成回源压力集中。适用条件是：已完成301规则部署、且新旧域名内容语义相同。此时应优先保证跳转链路正确，再按缓存过期时间逐步收敛，而不是把过渡期的版本差异当成故障处理。若新旧内容语义不同，则不属于切换期例外，仍需按前面的顺序定位。

把定位结果转成下一步动作

• 缓存键不含主机名：先改键，再复测随机性是否消失。
• 回源 Host 与首选域名不一致：先修边缘重写，再看规范链接是否统一。
• 某层版本串持续落后：检查该层的失效订阅是否覆盖全部内容类型。
• 处于域名切换期且跳转正确：按过期时间收敛，不急于强制刷新。

每一步的结果都直接决定下一步该动配置还是继续观察，避免在多层之间反复清缓存却找不到真正的分歧点。