蜘蛛发现 URL 只是第一步。它还要真正把页面取回去：建立连接、等待服务器返回首字节、下载 HTML，再解析其中的链接。任何一个环节太慢，抓取都会被打断或延后。很多站点把注意力放在链接和 Sitemap 上，却忽略了服务器响应时间对抓取节律的影响。
一次抓取里，蜘蛛在等什么
从站点角度看，一次抓取请求大致经历几个阶段：
- 连接阶段：DNS 解析、TCP 握手、TLS 握手。如果 DNS 慢或证书链有问题，蜘蛛可能在拿到内容前就失败。
- 等待首字节：服务器收到请求后，多久开始返回 HTML。这通常叫 TTFB，是动态程序、数据库查询、缓存命中率最直接的体现。
- 传输阶段：HTML 大小、是否分块传输、是否被压缩。页面体积过大，下载时间会拉长。
- 后续请求：如果蜘蛛需要渲染，还会请求 CSS、JS、字体和图片。这些资源如果阻塞或超时，渲染可能不完整。
超时是怎么发生的
抓取工具通常会设置连接超时和读取超时。连接超时指在规定时间内没建立连接；读取超时指连接已建立，但服务器迟迟不返回数据或传输中断。具体等待时间没有统一标准，不同工具和配置差异很大，常见范围在几秒到十几秒。
一旦超时，这次抓取会被标记为失败。蜘蛛可能稍后重试，也可能降低对该站点的抓取频率。对站点来说，问题不是单次请求失败，而是失败累积后，抓取节奏被整体拖慢。
慢响应带来的连锁反应
抓取配额是有限的。如果每个页面都要等很久，蜘蛛在同样时间里能抓的 URL 数量就会下降。新页面、更新页面、深层页面的发现和回访都会延后。
- 回访间隔拉长：蜘蛛会把更多时间花在等待上，减少对站点的访问次数。
- 抓取深度变浅：列表页、分页和归档可能来不及跟进，深层 URL 更难被发现。
- 渲染资源更容易失败：如果 HTML 本身就很慢，后续 JS 和接口请求更容易超时。
- 服务器压力叠加：响应慢往往伴随资源竞争，蜘蛛请求和用户请求互相挤压。
有些站点在压力大时直接返回 503 或 429。偶尔出现可以理解，但如果长期如此，蜘蛛会认为站点不稳定，主动放慢抓取。相比直接拒绝，更稳妥的做法是让爬虫请求也能稳定拿到内容，或至少返回明确的短时限流信号。
哪些环节最容易拖慢响应
从常见情况看，拖慢抓取响应的原因通常集中在几处：
- 动态查询未缓存：每次请求都查数据库、调接口，TTFB 随并发上升。
- 无 CDN 或缓存策略粗糙：静态资源反复回源，HTML 也没有合理缓存。
- 第三方脚本阻塞：页面头部引入大量外部 JS，渲染被拖住。
- 图片和视频未优化：传输体积大，移动端尤其明显。
- 日志或统计写入慢：请求结束时同步写日志、写队列，拖长整体响应。
站点可以做的检查与调整
与其猜蜘蛛为什么不抓，不如先看服务器给了什么响应。可以从这些点入手：
- 在访问日志中按蜘蛛 UA 过滤，统计抓取请求的响应时间分布，看慢请求集中在哪些路径。
- 单独监控 TTFB。如果动态页 TTFB 明显高于静态页，优先做缓存或静态化。
- 检查 5xx 和超时比例。少量偶发可以观察，持续出现就要查服务器、数据库或 CDN 回源。
- 给爬虫请求保留稳定通道。不要因为爬虫频率高就整段封禁，限速或降低优先级通常更合适。
- 保持 Sitemap 和内链清晰。它们负责发现和深度，但不能替代稳定的响应速度。
抓取超时往往不是链接问题，而是服务器没能在蜘蛛愿意等待的时间内给出内容。先修响应时间，再谈抓取频率和 URL 发现，顺序会更顺。
最后提醒一点：响应时间改善后，抓取恢复通常也需要一段时间。蜘蛛会根据历史表现调整回访节律，不会因为某一天变快就立刻回到高频。持续稳定比短期冲刺更有意义。