蜘蛛抓取一个 URL，本质上就是一次普通的 HTTP 请求。它能等多久、愿意重试几次，并不由你的站点决定。所以一个页面在自己浏览器里“转两秒就出来了”，在抓取侧可能已经超时离场。
抓取侧的等待是有限度的
多数抓取器会设置多重超时：DNS 解析、TCP 连接、首字节返回、整体读取。任何一环拖得太久，这次抓取都会被判为失败或直接放弃。失败不一定留下 5xx 记录——连接被这一端掐断时，服务器日志里往往只剩一次不完整的请求。
- 连接超时：握手阶段就卡住，常见于防火墙、限流或后端排队。
- 首字节超时：请求已到达，但应用层算得太久。
- 读取超时：页面开始返回了，却迟迟传不完。
三类常见的“慢”，表现并不一样
首字节慢：应用层在算
典型原因是每次请求都实时查库、实时拼模板、实时调外部接口。对蜘蛛来说，这类页面看起来和 5xx 差不多——拿不到内容，只是错误码换成了“无响应”。可以用 curl 之类的工具反复测 TTFB，看是稳定慢还是偶发尖刺：稳定慢多半是逻辑问题，尖刺则更可能是资源争抢。
传输慢：内容本身太重
HTML 没开压缩、内联了大量数据、一个列表页把上千条记录全铺进 DOM，都会让读取阶段变长。传输慢不一定直接触发超时，但会拉低同一时间能抓完的 URL 数量，长期看等于给整站降速。
连接不稳：半截响应
比一次性宕机更麻烦的是忽好忽坏：十次里有一次连接被重置、有一次传到一半断掉。抓取器看到的是不完整的页面，容易把它当成一次失败的抓取，而不会认为内容更新了。这类问题通常藏在网关、长连接复用不当，或后端进程重启的缝隙里。
怎么定位到底慢在哪一环
- 先在服务器日志里按蜘蛛 UA 过滤，把每类 URL 的响应时间排个序，找出最慢的一批。
- 对比同一 URL 在不同时间点的耗时，区分“一直慢”和“高峰才慢”。
- 用同一台机器、同一个 UA 从站外复测，排除本地网络干扰。
- 检查是否只有动态页慢、静态页正常；是否只有带参数的 URL 慢。
- 确认压缩、缓存、CDN 回源策略是否对蜘蛛请求也生效。
服务端可以做的一些调整
- 给高频访问的列表页、归档页加一层缓存，让蜘蛛拿到现成结果。
- 开启 gzip 或 brotli，并控制单页 HTML 体积，别把整站数据塞进一个页面。
- 把非关键的第三方调用移出首屏渲染路径，或在外部接口超时时直接降级输出。
- 限制单 IP、单 UA 的并发，避免一次抓取高峰把应用线程占满。
- 检查连接复用与超时配置是否匹配，别让后端先于抓取端断开。
慢下来之后，抓取节奏也会跟着变
抓取频次通常和站点的响应表现挂钩。持续超时、错误率偏高的站点，往往会被降低抓取速度，恢复也需要时间。反过来说，“故意把响应拖慢”并不是好用的限流手段：它挡的不只是蜘蛛，也会让正常用户对站点的体验一起变差。
把蜘蛛当成一个没有耐心的普通访客来对待：让它尽快拿到完整、可解析的 HTML，比研究它什么时候来更重要。
一个简单的自查清单
- 蜘蛛请求的 TTFB 是否和普通用户一致？
- 是否存在只对特定 UA 生效的限流或拦截规则？
- 日志里有没有大量中断、未完成的请求记录？
- 页面 HTML 体积是否明显超出必要？
- 抓取高峰时，响应时间是否成倍上涨？
这些项目不必一次性全做完，先修最慢的那一批 URL，通常就能看到抓取成功率的变化。