robots，多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /232f8a073d99.html
📄
robots，多层缓存返回不同版本时怎样定位一致性问题
先别急着改规则：把 CDN、反向代理、应用层和本地浏览器这四层缓存的响应逐一取出，对比 robots.txt 的正文、状态码和关键响应头，找出哪一层最先偏离源站，再决定清理顺序。一致性问题的根源通常是某一层缓存了旧文件、或者各层对同一路径给出了不同重写结果，而不是规则内容本身写错了。
先确定“源站版本”这个唯一基准
多层缓存不一致时，最容易犯的错是拿浏览器看到的版本当基准。浏览器还叠了本地缓存和 Service Worker，它的结果不能代表源站。正确顺序是绕开所有缓存直连源站，拿到那份文件作为基准，记下它的正文摘要、字节数和修改时间。
具体动作：用带随机查询串的请求直连源站，例如 curl -s "https://example.com/robots.txt?nocache=1"，保存输出。这一步的结果决定后面所有比较的参照物——如果源站本身就在两个版本之间摇摆，问题不在缓存层，而在发布流程，后续排查方向要整体换掉。
逐层取样，找出第一个偏离的缓存层
拿到源站基准后，按请求路径从外到内逐层取样，每一层都记录三样东西：正文、HTTP 状态码、以及 Cache-Control、Age、ETag 这类能说明缓存行为的响应头。判断依据是“哪一层开始与源站不一致”，而不是“哪一层看起来最新”。
- CDN 边缘节点：从不同地理位置的节点请求同一路径，看返回是否一致。
- 反向代理或网关：直接请求回源前的内部地址，绕开 CDN。
- 应用层输出：在应用内部打印实际生成的内容，确认它是否已经和源站文件不同。
- 本地浏览器：最后才看，并强制禁用缓存，避免把本地状态误判成服务端问题。
如果只有部分 CDN 节点返回旧版本，说明是边缘缓存未失效；如果所有节点都返回旧版本而反向代理是新的，问题集中在 CDN 到源站之间的缓存键或回源配置上。这一步的取样结果直接决定下一步是清缓存还是改回源逻辑。
区分三类常见成因，避免清错缓存
同样是“版本不同”，成因不同，处理动作也不同。可以用下面的证据组合来区分：
- 缓存过期策略不一致：源站返回的
Cache-Control是长缓存，但某层按短缓存处理，导致同一时刻各层新旧不一。证据是各层Age差异明显。 - 缓存键设计问题：带与不带查询串、不同 Host 头被当成不同对象，各自缓存了不同版本。证据是同一路径在不同请求形式下返回不同正文。
- 发布未触发失效：源站已更新，但清理指令没有覆盖全部节点或全部变体。证据是源站新、边缘旧，且手动清理单个节点后该节点立即变新。
第三种情况最容易被误判成“规则写错了”。如果手动清理一个节点后它马上返回新版本，就说明规则内容没问题，缺的是失效流程，下一步应该去补发布环节的清理动作，而不是改 robots 内容。
用一份可执行清单收尾
把上面的判断落成动作，顺序不要颠倒：
- 直连源站取基准，记录正文摘要与响应头。
- 逐层取样，标出第一个偏离源站的层。
- 根据
Age、缓存键、手动清理后的变化，判断属于过期策略、缓存键还是失效遗漏。 - 只清理确认偏离的那一层，清理后立即复取同一路径，确认它已与源站一致。
- 如果清理后再次偏离，说明失效流程本身有缺口，转去修发布链路，而不是反复手动清理。
需要提醒的是，抓取限制的生效与否和索引结果不是一回事，robots.txt 的变更也不等于可靠的索引移除；即使各层版本最终一致，也不代表抓取或收录会立刻按预期变化。一致性排查解决的是“各层看到的是不是同一份文件”，这个前提确认清楚之后，再去看抓取与索引层面的现象才有意义。
