入口頁能不能被顺利抓取，很多时候不取决于連結寫得好不好，而取决于服務器在蜘蛛敲门的那几秒有没有及时應答。响應超时是蜘蛛池运营里最容易被忽略、也最难靠多挂几個域名绕過去的环节。
超时在蜘蛛眼里是一次失敗的抓取
爬虫發起請求後會等待服務器返回响應。如果在设定的時間内没有拿到完整结果，這次抓取通常會被判定為失敗或中断。它和返回 5xx 的效果接近：蜘蛛没有拿到連結，也没有拿到内容，但這次抓取已经消耗掉了。
公開文档里提到的等待上限一般在几十秒量級，不同搜尋引擎、不同抓取類型並不一致。這個數字只适合当作底线參考，不适合当作目标。蜘蛛的抓取频率是動態調整的，長期贴着上限跑的响應速度，會让它降低對整站的抓取热情。
慢在哪里：把一次請求拆開看
- DNS 解析：解析慢或解析结果不稳定，請求還没到服務器就已经耗掉一部分時間。
- TLS 握手：證书鏈不完整、不支持會话复用，會多出一到两次往返。
- 首字节時間（TTFB）：後端查询、同步調用外部接口、資料库慢查询通常都堆在這里。
- 传輸與頁面体积：体积過大的 HTML 或阻塞渲染的外鏈脚本，會拉長整体耗时。
很多入口頁把耗时花在看不见的地方：每次請求都同步拉一次統計脚本、RSS 或第三方 API，這些調用一抖動，整頁就跟着卡住。
频繁超时之後會發生什么
單次超时影响有限，持續的慢响應會叠加成几個後果：
- 抓取预算被消耗在無效請求上，真正需要發現的 URL 被推後處理。
- 爬虫的並發與频率被自動調低，而恢复往往比下降慢得多。
- 超时與 5xx 混在一起时，容易被判讀成服務器故障，進而影响對整批域名的信任。
- 入口頁的價值被低估——連結明明挂着，却長期查不到抓取记錄。
不要把蜘蛛還會再来当成兜底策略。超时是复利式的损耗，一次两次看不出問题，長期就會体現在 URL 的發現速度上。
怎么排查
看平均值意义不大，重点看高分位數。
- 讀取訪問日誌中的請求耗时字段（如 $request_time 與 upstream_response_time），按入口頁、按时段分组，观察 p95 與 p99。
- 用 curl 的耗时分解參數，把 DNS、连接、TLS、首字节、總时長分開看，定位瓶颈落在哪一段。
- 把蜘蛛 UA 的請求單獨筛出来，確認變慢的是否恰好集中在爬虫高發时段。
- 检查是否有限流、WAF 或防爬中間件在特定條件下延迟了响應。
可以做的優化
- 入口頁尽量静態化或走缓存，避免每次請求都回源到動態逻辑。
- 把統計、推荐、外部 API 等非必要調用改成异步或延迟加载，不要阻塞主响應。
- 開啟 HTTP keep-alive 與會话复用，减少重复握手開销。
- DNS 交给稳定的解析服務，TTL 不要设得過短。
- 给入口頁設定獨立的监控阈值，把响應時間和可用性放在同一級別看待。
入口頁是蜘蛛進入目标頁的必经通道，它的响應速度實际上决定了整條抓取路径是否通畅。與其反复增加入口頁數量，不如先把已有的入口頁做得稳定、快速、可预期。