搜索引擎爬虫，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d121530a9c4d.html
📄
搜索引擎爬虫，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站响应正常、边缘节点却出现超时、5xx或返回内容不一致时，最该保留的不是一句“源站没问题”，而是能证明差异发生在哪一层的证据——同一URL、同一时间窗内的源站响应、边缘响应、请求头与响应头、节点标识、抓取日志，以及这些记录之间的对应关系。只保留源站截图，通常无法解释爬虫为什么失败。
先分清两个解释：边缘故障，还是爬虫看到了不同副本
源站正常而边缘异常，常见有两种解释。第一种是边缘节点自身故障或回源链路异常：源站能正常响应，但边缘在转发、缓存或连接阶段失败。第二种是爬虫命中了不同边缘副本或不同缓存版本：源站内容已更新，边缘仍返回旧内容，或者不同节点返回的HTML、状态码、跳转并不一致。两者都会表现为“源站没问题，但抓取结果不对”，处理方式却不同。
区分方法不是看单次请求，而是看同一时间窗内、同一URL、不同观察点的结果是否一致。如果源站与边缘的差异只出现在特定节点、特定时间段，更像边缘故障；如果差异稳定跟随某个缓存键、某个机房或某个内容版本，更像副本或缓存不一致。
必须保留的最小证据集
建议在异常发生时立即固定以下材料，而不是等节点恢复后再回忆：
- 请求与响应原文：完整URL、请求方法、请求头、响应状态码、响应头、响应体前若干KB。边缘与源站各留一份，便于逐字段对比。
- 时间与节点标识：请求发生的时间（含时区）、边缘节点或机房标识、回源标识。没有节点维度，后续无法判断是个别节点还是全局问题。
- 爬虫侧记录：抓取日志中的状态码、响应时间、User-Agent、抓取频率，以及是否出现重试。它能说明爬虫实际看到的是哪一层结果。
- 内容一致性样本：同一URL在源站与边缘的标题、正文关键段落、canonical、robots meta、结构化数据是否一致。只对比状态码会漏掉“200但内容不同”的情况。
- 变更记录：边缘配置、缓存规则、回源策略、证书或DNS最近的变更时间点。异常若紧跟变更出现，这是重要线索。
一个实际动作是：在异常节点上对同一URL连续取样，同时从源站直接取样，把两组响应按时间戳配对保存。这样做的结果是，你能判断差异是“边缘返回了源站没有的状态码”，还是“两边状态码相同但内容不同”，下一步排查方向会因此不同。
用一组假设例子理解证据如何影响决策
假设某页面在源站返回200且内容为新版，边缘节点A返回200但内容是旧版，边缘节点B返回503。此时若只保留“源站正常”的证据，容易误判为爬虫自身问题。若保留了三组配对样本，就能看出：节点B是可用性异常，节点A是缓存一致性异常，两者需要分别处理。
但要注意，请求量下降或抓取量归零本身不能单独证明边缘处理正确。它还可能来自抓取配额调整、robots规则变化、站点整体流量波动或爬虫调度变化。只有把抓取日志与边缘响应配对后，才能把“抓取减少”与“边缘异常”建立可核查的关联，而不是直接归因。
哪些证据不足以支撑判断
以下材料单独出现时，通常不足以定位问题：
- 只有源站curl结果，没有边缘侧同时间结果。
- 只有监控大盘的可用率曲线，没有具体URL的响应原文。
- 只有一张报错截图，没有时间、节点和请求头。
- 只有“已刷新缓存”的操作记录，没有刷新前后的对比样本。
另外，robots.txt的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS也不保证边缘链路无异常。这些事实提醒我们，边缘异常的证据要落在实际响应上，而不是落在配置是否存在上。
保留证据后，下一步怎么走
把证据按“源站—边缘—爬虫”三层对齐后，再决定动作。若差异集中在少数节点，优先核查这些节点的回源与缓存状态；若差异跟随内容版本，优先核查缓存键与刷新机制；若边缘与源站状态码一致但内容不同，优先核查内容分发链路而非源站发布流程。每一步动作后，重新采集同一组配对样本，用结果确认异常是否收敛，而不是仅凭一次刷新成功就结束排查。
