站点的抓取量出现下滑时，很多人第一反应是“蜘蛛不来抓了”，但更常见的情况是：蜘蛛还在来，只是每次请求等得太久，单位时间内能完成的抓取次数被拖了下来。服务器稳定性与抓取节奏之间是互相牵制的关系，排查时最好把两边放到同一条时间轴上看。
先确认波动发生在哪一侧
日志里至少有两条时间线索：请求到达的时间和响应结束的时间。如果请求间隔本身没变，但每条记录的响应耗时明显拉长，问题多半在站点侧；如果响应耗时正常，但同一时间窗内的请求条数变少，就要考虑抓取侧降低了对本域的抓取频次。
需要一起看的三组数据
- 按分钟聚合的请求条数，观察是否出现台阶式下降；
- 平均响应时间与 P95 响应时间，两者一起看才不会被少量慢请求误导；
- 5xx、超时与连接中断的比例，尤其是同一时间段内是否集中出现。
把这三组数据画在同一张时间轴上，通常能直接看出是“请求少了”还是“请求变慢了”。
稳定性波动的常见来源
响应时间突然抬升，往往不是单一原因，而是几个因素叠加：
- 缓存失效或击穿：批量 URL 同时回源，数据库压力集中释放；
- 定时任务与抓取撞车：生成站点地图、跑数据统计的时间段正好赶上抓取高峰；
- 动态参数过多：筛选、排序、分页参数让同一份内容反复生成；
- 第三方依赖拖慢：页面渲染时同步调用外部接口，接口抖动直接传导到 HTML 输出。
这些情况在日志上的表现相似，都是响应时间拉长；但恢复方式不同，需要结合服务器监控和慢查询记录进一步区分。
把日志时间窗和服务器指标对齐
只盯着爬虫日志，很难判断是站点变慢还是抓取变少。做法是把日志按 5 分钟或 10 分钟分桶，同时拉取同一时间段的 CPU、内存、数据库连接数、带宽等指标，逐桶比对。
一个可操作的核对顺序
- 先定位响应时间抬升的起始分钟；
- 看该分钟是否有部署、任务或缓存刷新记录；
- 再看 5xx 是否与慢请求同时出现，若同时出现，优先修错误而不是调抓取；
- 最后看请求条数是否在响应恢复后才回升。
如果 5xx 和超时反复出现在同一路径上，先修这条路径，而不是先去改抓取间隔。带错误的地址被反复请求，本身就是对抓取额度的浪费。
抓取节奏的调节思路
抓取节奏不是越慢越安全，也不是越快越好。合理的目标是让服务器在抓取高峰时仍能稳定返回 200，同时把响应时间控制在自己可以接受的范围内。
- 静态化与缓存：详情页、列表页尽量走缓存，减少每次抓取都穿透到数据库；
- 收敛参数组合：对筛选、排序类参数设定取舍规则，避免大量近似 URL 被反复生成；
- 错峰执行：把批量任务、站点地图生成放到抓取低谷时段；
- 分离动静资源：图片、脚本交给 CDN，避免占用源站连接；
- 观察而非猜测：调整后继续用同样的时间窗对比，确认响应时间与抓取条数是否同步变化。
与 URL 发现的关系
服务器长期不稳定还会间接影响 URL 发现：新地址首次被抓到时如果遇到超时，蜘蛛未必会立刻重试，发现到首抓的等待就会被拉长。因此，站点地图和内链里新增的入口，最好在提交后的一段时间内保证响应稳定，不要在这个窗口做大规模发布或架构调整。
小结
判断“抓取是不是被拖慢”，关键是把请求条数、响应时间和状态码分布放在同一个时间窗里比对。站点侧先把错误和慢查询压下去，抓取侧再谈节奏；顺序反了，往往既没有改善抓取，也掩盖了真实的稳定性问题。