服務器慢一点，蜘蛛不一定立刻走；但慢到某個程度，這次抓取就會以失敗收场。理解超时，重点不是背一個固定秒數，而是搞清楚蜘蛛在請求的哪一段等待、等待失敗之後會留下什么後果。
超时不是單一數字
抓取超时通常由几层限制叠加：DNS 解析、TCP 连接、TLS 握手、等待响應头、等待响應体。任何一层拖得太久，整次請求都可能被判為失敗。不同搜尋引擎、不同抓取组件给出的阈值並不统一，也會随服務器的歷史表現浮動。所以运营侧很难用一個精确數字去卡线，只能把整体响應時間压到明顯低于常见超时的水平。
一次請求的時間都花在哪
- 连接阶段：DNS 解析慢、握手耗时高，常见于解析服務不稳定或鏈路绕遠的情形。
- 等待首字节：後端程序、資料库、缓存未命中的時間都算在這里，是超时的高發区。
- 传輸阶段：頁面体积大、带宽被打满时，响應体的下载會被拖長。
多數抓取超时發生在第二段，也就是首字节迟迟不来。頁面本身很小，但接口調用了外部服務，或者查询没有走索引，效果和頁面變大是一样的：蜘蛛在门口干等。
超时之後會發生什么
一次超时通常不會立刻導致頁面被剔除，但會留下负面记錄。常见後果包括：该 URL 被推迟到更晚再试；同一批次里其他 URL 的抓取节奏被拖慢；如果某段時間内多次超时，抓取频率會被主動調低。更隐蔽的情况是，超时恰好發生在頁面生成到一半的时候，蜘蛛拿到的是残缺内容，連結没讀全，原本存在的 URL 發現路径就断了。
运营侧先看哪几個信号
- 服務器日誌中蜘蛛 UA 的响應時間分布，重点看尾部而不是平均值。
- 同一時間段里的 5xx 與超时，是否集中在某個目錄或某個接口上。
- 抓取日誌中是否存在同一 URL 短期内被反复請求，却始终没有成功记錄。
- Sitemap 與内鏈指向的頁面里，有没有一部分長期不见抓取记錄。
分阶段處理慢响應
不要一上来就扩容。先把慢的环节定位出来：如果是資料库查询，先看索引與慢查询；如果是外部接口，考虑加缓存或做降級，別让蜘蛛的請求卡在別人的服務上；如果是静態资源拖慢整頁，把非首屏内容延後加载。做完這些，再去考虑连接數、带宽和 CDN 的缓存命中率。
對于确實一时優化不動的頁面，可以先用更轻量的版本承接抓取，把重逻辑放到用戶交互之後。這样做的目的不是讨好蜘蛛，而是让頁面能稳定返回完整内容，Sitemap 和内鏈里的入口才真正有意义。
別忽略重试带来的压力
超时發生之後，蜘蛛往往會在稍後重试。如果頁面持續慢，同一 URL 的請求會叠加，服務器压力進一步上升，形成循环。這时與其反复去調抓取频率，不如先让最慢的几個入口變快。很多时候只要把头部几個高频 URL 的响應压下来，整体抓取节奏就會自己恢复。
抓取超时更多是服務器健康度問题，而不是抓取策略問题。响應稳定了，URL 發現和後續抓取才有讨论的空間。