蜘蛛發現 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 發現，顺序會更顺。
最後提醒一点：响應時間改善後，抓取恢复通常也需要一段時間。蜘蛛會根據歷史表現調整回訪节律，不會因為某一天變快就立刻回到高频。持續稳定比短期冲刺更有意义。