蜘蛛抓取一個 URL，本质上是一次普通的 HTTP 請求：建立连接、發送請求、等待响應、接收内容。它和你用浏览器打開頁面的区別在于，它没有耐心，也不會因為頁面“看起来快好了”就多等一會儿。超過自己设定的阈值，它會断開、记一筆，然後轉身去抓別的地址。所以服務器响應的快慢，直接决定了蜘蛛一次訪問能带回多少東西。
超时可能發生在哪几個阶段
很多人把“抓取超时”理解成一個笼统的概念，其實它至少分布在五個环节：
- DNS 解析：域名解析慢或解析结果不稳定，连接還没開始就卡住了。
- TCP 连接：连接队列满、防火墙丢包，握手要反复重试。
- TLS 握手：證书鏈不完整、协议版本過舊、跳轉過多，都會額外增加往返次數。
- 首字节時間（TTFB）：請求已经發出，後端還在算，這是最常见的一段。
- 内容传輸：首字节很快，但 HTML 主体几十上百 KB 且带宽被占满，讀完仍然超时。
這几段的排查方式完全不同。只看“抓取失敗”這一個數字，很容易把後端慢当成带宽問题，或者反過来。
為什么首字节時間最值得盯
TTFB 是後端真正處理請求所用的時間。它包含路由匹配、資料库查询、模板渲染，以及任何同步調用的外部接口。一個頁面如果 TTFB 長期在 1 秒以上，蜘蛛每次訪問都要付出更高成本；在抓取額度固定的情况下，它能跑的 URL 數量就會下降。
更麻烦的是，TTFB 往往是“波動”的，而不是稳定地慢。平均值看起来還行，但高峰期偶尔飙到几秒，蜘蛛遇到的恰恰是這些坏样本。
對蜘蛛来说，一個頁面的成本不只是字节數，還包括等待時間。等得越久，它能覆盖的 URL 越少。
慢頁面在日誌里通常長什么样
- 同一批 URL 的抓取間隔逐渐拉長，從每天一次變成几天一次。
- 响應碼里出現較多 5xx，或者請求被中断、没有留下完整狀態碼。
- 蜘蛛只抓列表頁和少數入口頁，深层頁面几乎不再出現。
- 抓取集中在低峰时段，和你自己的訪問高峰错開。
這些現象不一定意味着惩罚，更常见的解释是资源层面的自然结果：慢和失敗让它把机會挪到了別處。
常见拖慢首字节的原因
1. 未缓存的動態查询
列表頁、搜尋结果頁、标簽頁每次請求都重新查库，且查询没走索引。這類頁面往往還是内鏈最密集的地方，一旦變慢，影响面比想象中大。
2. 同步調用外部服務
頁面上有评论、推荐、匯率、天气之類的第三方接口，且是同步渲染。第三方抖動一次，你的 TTFB 就跟着抖一次。
3. 所有請求走同一條通道
图片、附件、導出文件和大 HTML 挤在一起。一個几百 MB 的下载請求占满连接，後面的請求只能排队。
4. 服務器本身接近上限
CPU、内存、连接數或带宽長期在 80% 以上，說明没有余量。抓取高峰與用戶高峰重叠时，双方都會變慢。
可以落地的處理方式
- 给關键路径设缓存：栏目頁、文章頁這類内容相對稳定，尽量走静態化或短周期缓存，把資料库压力让出来。
- 外部調用改成异步或超时降級：给第三方請求设一個很短的超时，取不到就渲染占位内容，不要拖住整個頁面。
- 分開资源通道：静態资源、大文件下载和 HTML 使用不同的服務或限速策略，避免互相挤占。
- 關注分位數而不是均值：看 95 分位和 99 分位的 TTFB，比看平均值更接近蜘蛛的真實体驗。
- 控制頁面体积：首字节再快，正文過大同样會让传輸阶段超时，尤其在带宽較差的环境下。
和 URL 發現的關系
慢不只是“少抓几個頁面”的問题。当你把重要 URL 放在一條又慢又深的路径上——比如要经過多层篩選、分頁和跳轉才能到達——蜘蛛可能在走到它之前，就已经用完了本轮的時間和請求數。把重要内容放在响應稳定的入口附近，比事後补救更有效。
Sitemap 能提供一份直接的 URL 清單，但它只解决“知道有哪些地址”；服務器能不能稳定、快速地回應，才决定這些地址會不會被真正抓完。