百度收录加速多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /516544205ab4.html
📄
百度收录加速多层缓存返回不同版本时怎样定位一致性问题
先看缓存链路上“谁在改写响应”以及“改写结果是否可被复现”。若同一 URL 在不同网络、不同 UA、不同入口下返回的 HTML 或状态码不一致，通常不是收录本身出了问题，而是某一层缓存把旧版本、压缩版本或带条件分支的版本固化了下来。定位时要先固定一个可复现的请求条件，再逐层剥离缓存，观察响应差异在哪一层消失。
先判断两种条件：缓存是“回源前改写”还是“回源后改写”
这两种条件对应完全不同的排查动作。回源前改写指 CDN、反向代理或应用层在请求到达源站前就决定了返回内容，例如按地域、UA、登录态或 A/B 分支返回不同 HTML。回源后改写指源站已经输出一份内容，但边缘节点或浏览器缓存保存了更早的版本，后续请求直接命中旧副本。
区分依据是：把请求直接打到源站 IP 并带上 Host，若源站返回的版本与线上不一致，问题更可能在回源前改写或源站自身分支；若源站返回一致、只有经过缓存层才不一致，则更可能是回源后缓存了旧版本。这个判断会直接决定下一步是查应用分支逻辑，还是查缓存键与刷新策略。
用可复现请求固定变量，再逐层剥离缓存
先选定一个具体 URL，记录完整请求条件：协议、Host、路径、查询参数、UA、Accept-Encoding、Cookie 是否携带。然后按顺序做三次请求，每次只改变一个变量。
- 直接请求源站，绕过 CDN 和反向代理，记录响应状态码、
Content-Length、ETag、Last-Modified以及正文中一个稳定片段。 - 请求 CDN 或反向代理地址，但带上一个能绕过缓存的查询参数或请求头，观察返回是否与源站一致。
- 请求线上普通地址，不加任何绕过参数，观察是否命中旧版本。
如果第 1 步与第 3 步不一致、第 2 步与第 1 步一致，说明缓存层保存了旧副本，问题在缓存键或刷新机制。如果第 1 步本身就与预期不一致，说明源站或应用层在输出不同版本，缓存只是把差异放大。这个动作的结果会决定下一步是清理缓存并调整缓存键，还是回到应用层排查分支条件。
检查缓存键是否漏掉了会改变正文的维度
多层缓存返回不同版本，常见遗漏条件是缓存键没有包含真正影响正文的请求维度。例如源站按 Accept-Encoding 返回不同压缩体，按 Cookie 返回登录态页面，按 UA 返回移动版或简化版，但中间缓存只按 URL 做键。这样第一个到达的版本会被复用给后续所有请求。
验证方法是构造两个只在疑似维度上不同的请求，其他条件完全一致，观察响应正文或 Vary 头是否变化。若响应正文变化但缓存层没有相应区分，就说明缓存键覆盖不足。实际动作是让缓存键包含该维度，或让源站对不该被缓存的请求返回明确的禁止缓存指令。结果会影响后续验证：如果修正缓存键后不同请求仍返回同一版本，就要继续查是否有上游缓存或浏览器缓存参与。
区分“收录异常”与“缓存版本异常”的证据
百度收录加速过程中，抓取量下降、索引量波动或搜索结果摘要陈旧，可能来自缓存版本不一致，也可能来自抓取限制、内容质量判断、站点结构变化或外部链接变动。缓存版本异常的可区分证据是：同一 URL 在固定请求条件下能稳定复现两个不同正文，并且其中一个版本明显早于另一个。
如果无法稳定复现，只是偶尔看到旧摘要，就不能单独归因于多层缓存。此时应继续收集带时间戳的响应样本，而不是直接刷新缓存或改 robots.txt。robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些动作不能替代对缓存一致性的定位。
例外：源站主动输出多版本时，缓存不是根因
假设一个场景：源站根据 Accept-Language 返回不同语言版本，但缓存层只按 URL 缓存，导致英文请求拿到中文页面。此时清理缓存只能短期恢复，下一次请求仍会重新固化错误版本。正确动作是让缓存键包含语言维度，或让源站对这类请求返回 Vary: Accept-Language，并确认中间缓存是否遵守该头。
另一个例外是源站自身存在发布延迟：新版本已部署，但部分应用节点仍返回旧模板。这种情况下，直接请求源站的不同节点会得到不同正文，缓存层只是被动保存了其中一个。此时应先在源站内部核对发布状态和节点一致性，再处理缓存刷新。只有确认源站输出一致后，缓存层的不一致才是需要优先修复的对象。
