蜘蛛抓取一個 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，通常就能看到抓取成功率的變化。