服务器慢一点，蜘蛛不一定立刻走；但慢到某个程度，这次抓取就会以失败收场。理解超时，重点不是背一个固定秒数，而是搞清楚蜘蛛在请求的哪一段等待、等待失败之后会留下什么后果。
超时不是单一数字
抓取超时通常由几层限制叠加：DNS 解析、TCP 连接、TLS 握手、等待响应头、等待响应体。任何一层拖得太久，整次请求都可能被判为失败。不同搜索引擎、不同抓取组件给出的阈值并不统一，也会随服务器的历史表现浮动。所以运营侧很难用一个精确数字去卡线，只能把整体响应时间压到明显低于常见超时的水平。
一次请求的时间都花在哪
- 连接阶段：DNS 解析慢、握手耗时高，常见于解析服务不稳定或链路绕远的情形。
- 等待首字节：后端程序、数据库、缓存未命中的时间都算在这里，是超时的高发区。
- 传输阶段：页面体积大、带宽被打满时，响应体的下载会被拖长。
多数抓取超时发生在第二段，也就是首字节迟迟不来。页面本身很小，但接口调用了外部服务，或者查询没有走索引，效果和页面变大是一样的：蜘蛛在门口干等。
超时之后会发生什么
一次超时通常不会立刻导致页面被剔除，但会留下负面记录。常见后果包括：该 URL 被推迟到更晚再试；同一批次里其他 URL 的抓取节奏被拖慢；如果某段时间内多次超时，抓取频率会被主动调低。更隐蔽的情况是，超时恰好发生在页面生成到一半的时候，蜘蛛拿到的是残缺内容，链接没读全，原本存在的 URL 发现路径就断了。
运营侧先看哪几个信号
- 服务器日志中蜘蛛 UA 的响应时间分布，重点看尾部而不是平均值。
- 同一时间段里的 5xx 与超时，是否集中在某个目录或某个接口上。
- 抓取日志中是否存在同一 URL 短期内被反复请求，却始终没有成功记录。
- Sitemap 与内链指向的页面里，有没有一部分长期不见抓取记录。
分阶段处理慢响应
不要一上来就扩容。先把慢的环节定位出来：如果是数据库查询，先看索引与慢查询；如果是外部接口，考虑加缓存或做降级，别让蜘蛛的请求卡在别人的服务上；如果是静态资源拖慢整页，把非首屏内容延后加载。做完这些，再去考虑连接数、带宽和 CDN 的缓存命中率。
对于确实一时优化不动的页面，可以先用更轻量的版本承接抓取，把重逻辑放到用户交互之后。这样做的目的不是讨好蜘蛛，而是让页面能稳定返回完整内容，Sitemap 和内链里的入口才真正有意义。
别忽略重试带来的压力
超时发生之后，蜘蛛往往会在稍后重试。如果页面持续慢，同一 URL 的请求会叠加，服务器压力进一步上升，形成循环。这时与其反复去调抓取频率，不如先让最慢的几个入口变快。很多时候只要把头部几个高频 URL 的响应压下来，整体抓取节奏就会自己恢复。
抓取超时更多是服务器健康度问题，而不是抓取策略问题。响应稳定了，URL 发现和后续抓取才有讨论的空间。