抓取是否顺畅，很多时候不取决于内容质量，而取决于服务器在蜘蛛来访的那几百毫秒里有没有稳定给出响应。同一批 URL，在响应稳定的日子里被逐层展开，在超时和 5xx 集中的时段里则可能整段停顿，之后很长时间不再回访。
一、抓取中断在日志里通常长什么样
把日志按响应状态和时间戳排一遍，中断往往集中在几类记录上：
- 连接超时或读取超时：请求到达但服务端没能在合理时间内完成响应，蜘蛛侧记为超时，这个 URL 相当于没被抓到。
- 5xx 突发：数据库连接池耗尽、上游接口拖慢、发布重启，都会在短时间内产生成片 500、502、503。
- 连接被重置：网关、防火墙、限流组件主动断开，日志里常表现为请求未完成或异常关闭。
- 200 但极慢：状态码正常，耗时从几百毫秒升到数秒，蜘蛛会主动降低对整站的抓取并发。
二、为什么超时和 5xx 比 404 更容易打乱节奏
404 表达的是“这个地址不存在”，蜘蛛会把它记为无效 URL 并逐步减少访问。超时和 5xx 表达的是“现在拿不到”，属于临时性失败，蜘蛛通常会稍后重试；但如果重试仍然失败，重复的失败记录会累积成对站点稳定性的负面判断。
判断标准可以简化为一句话：404 消耗的是入口价值，超时和 5xx 消耗的是抓取信任。
这也是为什么恢复之后抓取量往往不会立刻回到原有水平——爬虫需要重新试探，逐步提高并发，这个过程有时比中断本身更长。
三、按时段统计失败率的做法
- 把当天日志按小时切分，分别统计总请求数、超时数、5xx 数、平均响应时间。
- 算出每小时的失败率，标出明显高于日常基线的时间窗。
- 把失败窗口与运维事件对齐：发布、备份、批量任务、缓存刷新、上游接口变更。
- 对照同一时间窗内被抓取的 URL 类型，看是整站受影响，还是集中在某类动态页或某台后端。
做完这四步，通常能区分是“整体容量不足”还是“个别入口把资源拖垮”。后者更常见，例如某个筛选组合页会触发大量查询，被反复抓取后拖慢整台机器。
四、恢复阶段值得注意的几点
- 先确认失败率回到基线，再考虑新增入口或提交新 URL，避免在脆弱期扩大抓取面。
- 对确实无法承载的参数组合，用 robots.txt 或链接收敛减少入口，而不是放任其反复超时。
- 如果是单台后端的问题，先摘除异常节点，观察失败率是否随流量迁移而下降。
- 恢复后的一两天内，重点看回访量而非新增抓取量，回访恢复通常意味着信任在修复。
五、日常核对清单
- 是否有稳定的响应时间基线，而不只看可用性监控里的“是否在线”。
- 超时值是否与自身最慢的正常页面匹配，过短会误伤慢页面，过长会让蜘蛛空等。
- 5xx 是否有告警，并且能关联到具体的发布动作。
- 限流规则是否对搜索蜘蛛做了区分，避免正常抓取被当作攻击拦截。
- 是否按 URL 类型记录平均响应时间，便于发现某类页面在拖慢整体。
服务器稳定性不是一次性优化，而是一条需要持续观测的曲线。把失败率、响应时间和抓取量放在同一张表里看，很多“内容没问题却不被抓”的疑问，会在时间轴上找到对应的解释。