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

robots.txt：源站正常而边缘节点异常时应保留哪些证据，先固定假设情境：源站与边缘节点返回不同内容

直接回答：应同时保留源站与边缘节点两侧的原始响应，包括各自返回的robots.txt正文、HTTP状态码、响应头、请求时间与节点标识，再保留同一时刻从不同网络发起的抓取结果。只有把“源站返回什么”和“边缘节点返回什么”分开固定下来，才能判断是缓存、回源、节点配置还是安全策略造成的差异。

先固定假设情境：源站与边缘节点返回不同内容

假设某站点把robots.txt放在源站，前面经过CDN或反向代理。运维在源站直接请求时看到的是允许抓取的版本，而通过公网域名请求时却看到另一段内容，甚至状态码不同。这个现象不能直接归因于搜索引擎，也不能只凭一次浏览器访问下结论，因为浏览器可能命中本地缓存、中间缓存或不同边缘节点。

此时需要做的第一个动作是分别记录两条路径的原始响应：一条绕过边缘节点直连源站，一条走正常公网链路。记录结果会决定下一步是查缓存策略、查回源配置，还是查节点发布流程。如果两条路径返回完全一致，问题就不在边缘节点；如果只在部分节点不一致，排查范围应缩小到节点组和缓存键。

证据一：两侧的原始正文与状态码必须成对保存

只保存截图不够，因为截图无法证明响应头、状态码和请求时间。应保存可复核的原始文本，并让每条记录都带请求时间。重点核对以下字段：

• HTTP状态码：是200、403、404还是5xx，不同状态码指向不同处理路径。
• Content-Type与Content-Length：正文类型和长度是否一致，可暴露返回了错误页或空文件。
• Cache-Control、Age、ETag、Last-Modified：用于判断边缘节点是否在复用旧副本。
• 节点标识：如响应头中的边缘节点编号、机房代码或请求ID，便于定位是哪一类节点异常。
• User-agent与请求来源IP：确认测试请求是否被安全策略区别对待。

这些字段组合起来，才能区分“边缘节点缓存了旧robots.txt”和“边缘节点回源失败后返回了默认拦截页”这两种完全不同的原因。若只看到正文不同就改源站文件，可能把本来正确的内容覆盖掉。

证据二：用同一时刻的多点请求区分缓存与配置问题

源站正常而边缘异常，常见解释有三种：边缘缓存未刷新、部分节点回源失败、边缘层安全规则改写了响应。区分方法不是反复刷新浏览器，而是在尽量接近的时间点，从不同网络位置请求同一URL，并记录每次命中的节点标识和Age值。

如果同一节点连续返回旧内容且Age持续增大，更接近缓存副本未过期；如果不同节点返回不同版本，更接近节点发布不一致；如果所有走边缘的请求都返回403或5xx，而源站直连正常，则应优先检查边缘层的访问控制与回源链路。这里要注意：请求量或抓取量突然归零，不能单独证明robots.txt处理正确，也可能是抓取预算调整、站点整体不可达或搜索引擎侧策略变化。

证据三：保留搜索引擎侧可观察到的结果作为旁证

搜索引擎抓取到的robots.txt与实际访问结果可能因时间差而不同。可以保留搜索资源平台中robots.txt抓取记录、站点地图提交状态和索引状态的时间点，但这些只能作为旁证，不能替代源站与边缘节点的原始响应。robots.txt的抓取限制不等于可靠的索引移除；站点地图也不保证收录。若需要确认某个URL是否仍可被抓取，应结合该URL的实际响应和索引状态分别核对。

一个实际动作是：在修复边缘节点后，重新从多个节点请求robots.txt，确认正文、状态码和缓存头一致，再观察搜索引擎侧抓取记录是否更新。这个动作的结果会影响下一步——如果边缘节点已一致但搜索引擎侧仍显示旧内容，应继续等待其缓存刷新，而不是继续修改源站文件。

决策顺序：先证据后修改，避免误改源站

建议按以下顺序处理，每一步都留下可复查记录：

1. 直连源站请求robots.txt，保存正文、状态码和响应头。
2. 通过公网域名请求同一路径，保存正文、状态码、响应头和节点标识。
3. 对比两侧差异，判断是缓存、回源、安全策略还是发布不一致。
4. 只针对判断出的环节修改，例如刷新缓存、修正回源规则或统一节点配置。
5. 修改后重复第1、2步，确认两侧一致，再观察搜索引擎侧记录。

如果跳过第1、2步直接改源站，很可能在源站本来正确的情况下制造新的不一致。保留证据的目的不是追求形式完整，而是让每一次修改都有可验证的前后对比。