百度爬虫源站正常而边缘节点异常时应保留哪些证据

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

百度爬虫源站正常而边缘节点异常时应保留哪些证据

先给结论：当源站日志显示百度爬虫请求正常、但边缘节点（CDN、WAF、反代或负载均衡）出现异常时，应优先保留“能证明异常只发生在边缘层”的时间对齐证据——边缘访问日志中百度爬虫 UA/IP 的响应码序列、回源日志与源站日志的同一请求 ID 对照、以及异常时段的边缘配置快照。缺权限时，最小动作是导出边缘侧近 24 小时按 UA 过滤的响应码分布，并记录导出时刻与节点名称；这只能证明边缘层行为，不能直接推出百度已降权或收录会变化。

两种条件下该保留什么：有边缘日志权限 vs 只有源站日志

证据取舍取决于你能否读到边缘侧数据，而不是取决于源站是否正常。

选择依据很简单：边缘异常的核心矛盾是“源站看到的请求”和“爬虫实际收到的响应”之间出现断层。只有边缘日志能直接落在断层上；只有源站日志时，你只能间接推断，因此证据要求更保守。

时间对齐是第一步：用请求标识把两侧日志串起来

源站正常但边缘异常，最常见的误判是把两侧日志的时间戳直接比较。边缘节点时钟、日志落盘延迟、缓存命中不回源，都会让同一请求在两侧时间不同或不出现。

  1. 在边缘侧导出异常时段按百度爬虫 UA 过滤的日志，保留原始时间戳与时区标注。
  2. 在源站侧导出同一时段日志，优先找带请求 ID、trace ID 或 X-Forwarded-For 的记录。
  3. 用请求 ID 匹配，而不是用时间戳匹配；匹配不上的请求，先归因于缓存命中或边缘拦截，不要直接判定为“爬虫没来”。
  4. 记录导出动作本身：导出时间、节点名称、过滤条件、日志条数。下一步排查依赖这些元信息，否则后续无法复现。

如果边缘侧日志里百度爬虫 UA 的响应码集中在 403、429 或 5xx，而源站同路径返回 200，那么证据指向边缘策略或回源链路；如果边缘侧根本没有对应记录，先怀疑过滤条件、采样或日志级别，而不是断言爬虫停止抓取。

需要固定下来的三类证据及其例外

1. 边缘配置快照

保留异常时段的 WAF 规则、限速阈值、UA 黑名单、回源超时设置。配置改动往往在异常之后才被回滚，事后无法还原当时状态。例外：若配置由平台托管且不提供历史版本，只能记录当前值与变更工单号，并明确标注“无法还原异常时点配置”。

2. 响应码与响应体样本

对百度爬虫 UA 命中的异常响应，保留响应码、响应头（尤其 Cache-Control、Set-Cookie、重定向目标）和响应体前若干字节。验证码页、拦截页、空 200 都会表现为“源站正常但爬虫拿到异常内容”。

3. 抓取频次与路径分布

保留异常时段百度爬虫请求的路径分布与频次变化。频次下降或归零有多种解释：边缘拦截、爬虫自身调度、站点整体抓取预算变化。单靠频次归零不能证明是边缘导致，必须与响应码证据一起看。

一个假设例子：如何用证据区分两种原因

假设某站点源站日志显示百度爬虫对 /list 返回 200，持续正常；边缘侧同路径对百度爬虫 UA 返回 403，且集中在某一节点。此时可执行动作是：临时对该节点放行百度爬虫 UA 并记录放行时间，观察边缘日志中 403 是否转为 200。若转为 200，证据支持“边缘规则误伤”；若仍为 403，则需检查回源链路或上层策略。这个动作的结果直接决定下一步是调整 WAF 规则还是继续排查回源，而不是先改 robots.txt 或提交站点地图。

注意：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。边缘放行后即使抓取恢复，也不能据此承诺收录或排名变化。

缺权限时的最小动作与不能推出的结论

没有边缘日志权限时，仍可执行的最小动作是：从多个地域用百度爬虫 UA 发起探测，记录响应码、响应头与时间，并保存探测脚本与原始输出。这能提供“外部可见行为”的样本，但样本量小、IP 不代表真实爬虫，不能等同于百度爬虫的实际体验。

由此不能推出：百度已降低抓取频次、站点被惩罚、收录必然下降。这些结论需要百度侧数据或更长时间的行为证据。可推出的只有：在探测覆盖的节点与时刻，该 UA 收到了异常响应。下一步应据此向边缘服务方索取对应时段的日志，而不是先改动源站内容或抓取规则。

图1 图2
nginx