讨论抓取预算时，容易只盯 URL 數量、内鏈和 Sitemap，却忽略一個更底层的變量：蜘蛛與服務器之間是怎么建立和复用连接的。同样的頁面數量，连接层配置不同，抓取节奏可能差出數倍。這一层不直接决定收錄，但會明顯影响抓取效率與回訪密度。
抓取是连接上的连續對话
蜘蛛抓取一批 URL 时，通常不是每個請求都重新做一次完整握手。它會尽量复用已有连接，按並發窗口持續發送請求。如果连接建立成本高、复用被中断，或者服務器對單一来源 IP 的並發连接有限制，蜘蛛就會在“等待连接”上消耗時間，而不是在“传輸 HTML”上。表現出来就是日誌里請求時間跨度被拉長，抓取频次看起来没有下降，但實际完成量變少。
三個容易被忽略的连接层變量
1. Keep-Alive 與连接關閉策略
服務器或中間层如果频繁主動關閉空闲连接，蜘蛛每次發請求都要重新握手，TLS 握手尤其昂贵。核對时看响應头里 Connection 的取值，以及日誌中同一 IP 的請求是否呈現“短连接”特征。反向代理和负载均衡的健康检查、超时時間設定也可能誤伤長连接。
2. HTTP/2 多路复用與並發流
HTTP/2 允许在一條连接上並行多個請求，理论上對抓取更友好，但前提是服務器正确啟用且没有把並發流限制得過低。若 HTTP/2 协商失敗退回 HTTP/1.1，抓取端會退回到每個域名 6 個左右並發连接的舊模式。核對时確認 ALPN 协商结果、TLS 版本，以及是否因為某個中間节点不支持而静默降級。
3. 服務器端並發與限流
應用服務器、WAF 或 CDN 可能對單 IP 並發连接數、每秒請求數设限，超出後返回 429、503 或直接重置连接。蜘蛛收到這類信号會退避，抓取节奏自然放缓。核對时把限流阈值與蜘蛛實际並發做對照，而不是只看平均 QPS。
核對顺序建议
- 先用日誌按 IP 和 UA 聚合，看單次抓取會话的连接數、請求間隔和狀態碼分布。
- 检查响應头中的 Connection、Keep-Alive、Server、Via 等字段，判断连接是否被中間层改寫。
- 用 curl 或類似工具观察 ALPN 與 HTTP 版本协商结果，確認没有静默降級。
- 對照 CDN、WAF、负载均衡的並發與限流配置，確認蜘蛛不在被限制的范围内。
- 若發現连接层問题，優先調整超时和限流參數，再观察抓取完成量是否變化。
连接层不會让内容變得更好，但它决定了内容有没有被及时取走。
常见誤判
- 把抓取變慢直接归因于内容质量，忽略连接被限流。
- 只看平均响應時間，不看连接建立耗时和並發完成量。
- HTTP/2 已開啟就預設生效，不检查协商是否降級。
- 調整限流後立刻期待抓取量上升，忽略蜘蛛自身調度周期。
连接复用、並發上限和限流策略属于基础设施层，調整起来通常比改模板更快。建议每次改完只動一個變量，用日誌里的完成量而不是主观感受来判断效果。抓取节奏的改善往往是渐進的，需要一段時間观察。