robotstxt：源站正常而边缘节点异常时应保留哪些证据，两个解释：缓存旧副本，还是边缘改写响应
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /376182364c65.html
📄
robotstxt：源站正常而边缘节点异常时应保留哪些证据，两个解释：缓存旧副本，还是边缘改写响应
先给结论：源站返回的 robots.txt 正常，不代表边缘节点返回的内容可信。此时最该保留的不是“我刷新过”的截图，而是同一时刻、同一路径下源站响应与边缘响应的原始对照，包括状态码、响应头、正文完整内容、请求标识和获取时间。只有这些证据能区分“边缘缓存了旧规则”与“边缘对请求做了改写或拦截”，下一步动作完全不同。
两个解释：缓存旧副本，还是边缘改写响应
边缘节点异常通常有两种成立条件不同的解释。
第一种是缓存旧副本。源站已经更新 robots.txt，但边缘仍按旧缓存键返回历史内容。它的特征是：正文与源站旧版本一致，状态码通常仍是 200，响应头里可能带年龄、缓存命中或过期相关字段，且同一路径在不同地区或不同网络下结果不一致。
第二种是边缘改写或拦截。源站内容没变，边缘基于规则、鉴权或安全策略替换了正文、改成 403/404/5xx，或返回一段 HTML 错误页。它的特征是：正文与源站任何历史版本都不匹配，响应头里出现源站没有的字段，或正文类型从纯文本变成 HTML。
两者都会让抓取端读到错误规则，但处理路径不同：前者要处理缓存键与刷新，后者要查边缘规则链。因此证据必须能指向其中一种，而不是只证明“我这里看到的不对”。
必须同时保留的四类原始证据
以下动作建议在发现异常后立即执行，避免缓存过期后现场消失。
- 同一路径的双份响应。用相同 URL 路径分别请求源站直连地址和边缘地址，保存完整响应，不要只留状态码。正文要原样保存，包括注释行和空行，因为规则差异常出现在细节里。
- 完整响应头。记录状态码、内容类型、内容长度、缓存相关字段、服务端标识和请求标识。响应头是区分“缓存命中”与“规则改写”的主要依据。
- 时间与请求上下文。记录获取的绝对时间、请求方法、是否带条件请求头、来源网络或地区。缺少时间，后续无法判断缓存是否已过期。
- 可复核的请求标识。保留边缘返回的请求编号或追踪标识，便于向边缘侧定位同一次请求。若没有该标识，至少保留完整请求参数。
保存后先做一次对照：如果边缘正文等于源站旧版本，优先按缓存问题处理；如果边缘正文与任何版本都不符，转向规则链排查。这个判断结果直接决定下一步找谁。
一个假设例子：如何用证据排除错误方向
假设某站点更新 robots.txt 后，直连源站看到新规则，边缘地址仍返回旧规则。若只保留“边缘返回旧规则”的截图，容易直接判定为缓存未刷新并反复刷新。但如果同时保留了响应头，发现边缘响应的内容长度与源站旧版本一致、且带有缓存命中标记，就能支持缓存解释；反之，若内容长度与任何版本都不一致、内容类型变成 HTML，就应怀疑边缘改写。这个例子的数字仅用于说明比较方法，不代表真实站点数据。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。因此即使边缘返回了正确的禁止规则，也不能据此推断已抓取页面会按预期从索引中消失；这部分要另行核查。
证据到手后的动作与结果
拿到对照证据后，第一步是固定一份只读副本，标注获取时间与来源，避免后续被覆盖。第二步按证据指向分流：疑似缓存时，核对缓存键是否包含主机名、协议或路径变体，并确认刷新范围是否覆盖异常节点；疑似改写时，核对边缘规则链中是否有针对该路径的重写、鉴权或错误页配置。
动作的结果会改变下一步：如果刷新后边缘正文与源站一致，说明缓存解释成立，接下来应检查缓存键设计为何导致旧副本留存；如果刷新后正文仍异常，缓存解释被削弱，应转向规则链与节点配置。若多次请求结果在不同节点间不一致，说明问题可能局限在部分节点，证据中必须保留节点或地区标识，否则无法缩小范围。
最后，把“源站正常”和“边缘正常”分开记录，不要合并成一句结论。源站正常只证明源站侧配置无误，边缘异常仍需独立证据链。缺少请求标识时，至少保留时间、路径与完整响应，仍可用于后续比对。
