谈抓取时，多數人先看内容质量和入口數量，但還有一個容易被忽略的层面：连接。蜘蛛在單位時間内能發出多少請求，不只取决于服務器處理速度，也取决于连接是否被复用。同一台服務器，内容完全一样，连接配置不同，抓取表現可能差出一截。
连接复用為什么會改變抓取节律
在 HTTP/1.1 下，一個請求通常對應一條 TCP 连接。如果服務端愿意保持连接，蜘蛛可以在同一條连接上连續請求多個 URL，省掉反复的握手開销；如果服務端每次都返回 Connection: close，或者把 keep-alive 超时设得很短，蜘蛛就得不断新建连接、重新握手，單位時間内能完成的請求自然變少。
更隐蔽的情况是负载均衡：同一只蜘蛛的請求被分散到不同後端节点，各自维護连接，看起来连接數不少，實际可复用的會话很少。
几個可以直接检查的点
- 看响應头里是否存在 Connection: close，或者 keep-alive 的超时時間是否明顯偏短。
- 看 TLS 握手次數與請求數的比例，比例接近一比一，說明连接几乎没被复用。
- 看负载均衡是否開啟了會话保持，以及空闲连接被回收的時間。
- 看訪問日誌里同一来源 IP 的连接持續時間分布，判断是長连接還是频繁短连接。
HTTP/2 带来的變化與新的盲区
啟用 HTTP/2 後，多條請求可以共用一條连接，服務端看到的並發從“连接數”變成了“流數”。好處是握手成本下降、抓取节律更平稳；但也會带来新的观察盲区：只看连接數的监控會顯示得很平静，實际單條连接上可能积压了大量請求。
另一種情况是流控窗口設定過小，或者後端某個接口排队，導致個別流迟迟拿不到响應。蜘蛛侧看到的是請求超时或迟迟不返回，而服務器整体负载並不高。排查时需要把流級別的等待時間單獨拉出来看，而不是只看 CPU 和带宽。
观测指标建议
- 單位時間抓取請求數：按小时統計，观察調整前後的變化趋势。
- 平均连接持續時間：過短說明复用不足，過長要確認是否有請求卡住。
- 握手次數與請求數之比：越低說明复用越好。
- 超时與重试比例：與连接层指标放在同一張图上對照。
连接层調整只影响抓取過程的顺畅程度，並不能决定頁面是否被收錄或获得排名，把两者混為一谈容易做出错誤决策。
落地顺序
- 先確認現状：抓一份包含连接信息的抓取日誌样本，作為基线。
- 調整 keep-alive 超时與單连接最大請求數，幅度不要太大，一次只改一個參數。
- 確認 HTTP/2 或 HTTP/3 的啟用范围，注意部分老舊中間件對多路复用的支持並不完整。
- 調整後观察一到两周，重点看抓取請求數與超时率的曲线，而不是某一天的數字。
连接层的問题往往不顯眼，但它决定了同样的内容、同样的入口，蜘蛛能不能在同样的時間里走完。把它和 URL 發現、内鏈路径放在一起看，排查思路會更完整。