Baiduspider抓取：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c3df09261872.html
📄
Baiduspider抓取：源站正常而边缘节点异常时应保留哪些证据
结论先给：如果源站回源日志显示正常，而边缘节点对 Baiduspider 返回了错误状态、空内容或异常跳转，那么最该保留的不是“抓取量下降”这个结果，而是能证明差异发生在哪一层的原始证据。需要同时留下边缘侧响应记录、源站回源记录、请求标识和变更时间线，否则事后只能靠推测，无法判断是节点缓存、回源链路还是策略配置造成的。这个结论有一个反例：如果边缘节点日志本身不记录状态码或上游地址，那么保留再多源站日志也无法完成对照，此时应先确认日志字段是否够用，再谈取证。
为什么源站正常不能直接推出抓取正常
源站正常只说明应用和数据库这一层没有报错，它不覆盖边缘节点到源站之间的那一段。Baiduspider 请求先到边缘节点，节点可能命中缓存、执行重写规则、做访问控制或转发到另一个上游。任何一步出错，源站都可能完全看不到这次请求，或者只看到一次被改写过的回源请求。
因此判断时要区分两种现象：源站日志里没有对应记录，说明请求根本没到源站；源站日志里有记录但状态码与边缘侧不一致，说明中间层改写了响应。这两种现象的下一步动作完全不同，前者查边缘路由和拦截规则，后者查缓存和响应改写。
必须保留的四类证据
取证的目标是让每一条 Baiduspider 请求都能被两端对上。建议按下面四类留存，缺哪一类都会让对照断链。
- 边缘侧访问记录：包含请求时间、User-Agent、请求路径、返回状态码、响应字节数、命中的节点标识和缓存状态。字节数为 0 或明显偏小，往往比状态码更能暴露空响应问题。
- 源站回源记录：同一时间窗内的回源请求日志，包含来源地址、请求路径、状态码和响应耗时。它用来证明请求是否真正到达应用层。
- 请求标识：边缘节点写入并透传到源站的请求 ID 或追踪头。没有它，两端日志只能靠时间戳近似匹配，并发一高就会错配。
- 变更时间线：节点配置、缓存规则、重写规则、证书和回源地址的修改时间。异常开始时间与变更时间的先后关系，是区分“配置引起”和“外部波动”的关键依据。
用一组可核对的对照来区分原因
把同一路径、同一时间窗的两端记录并排比对，通常会出现三种可区分的情况。
- 边缘返回 5xx，源站无记录：问题在边缘到源站之间，优先查回源地址、超时设置和节点健康状态。
- 边缘返回 200 但字节数接近 0，源站返回 200 且有正常内容：问题在响应传输或缓存写入环节，优先查内容压缩、分块传输和缓存策略。
- 边缘返回 3xx，源站返回 200：问题在边缘重写或跳转规则，优先查规则命中的路径条件。
假设某路径在边缘侧连续出现状态码 200、响应字节数为 0，而源站同一时间窗内该路径的回源记录正常且字节数稳定。这个对照只能说明差异发生在边缘侧的处理或传输环节，不能直接断定是缓存导致，因为压缩配置错误、响应头冲突或节点局部故障也能产生同样表现。要缩小范围，需要再取一个未命中缓存的请求做对照：如果绕过缓存后字节数恢复正常，缓存环节的嫌疑才上升。
哪些证据容易被误当成结论
抓取量下降本身不是证据，它只是结果。请求量归零也可能来自站点自身屏蔽、Baiduspider 调度变化、网络波动或统计口径调整，不能单独证明边缘节点处理正确或错误。同理，边缘节点返回 200 也不等于内容正确，空响应和错误页同样可以带 200 状态码。
还要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些与边缘异常无关，不要把它们混进本次对照，否则会干扰对中间层问题的判断。
下一步动作与结果如何影响判断
先固定一个时间窗和一组路径，把边缘侧与源站的记录按请求标识对齐，导出为可复核的文件并记录导出时间。如果对齐后发现差异集中在特定节点，下一步就针对该节点复现请求并保留完整响应头；如果差异分散在多个节点，则应优先检查全局配置和回源链路。复现结果会直接决定后续是调整节点配置，还是回退最近的规则变更——在拿到对照证据之前，不建议先改配置，否则原始状态会丢失，后续无法验证改动是否真正解决了问题。
