抓取日誌里看到的請求數只是结果，背後還有一层常被忽略的東西：蜘蛛是用多少條连接、以什么方式把這些請求送到服務器上的。同样的抓取量，连接行為不同，服務器感受到的压力差別很大，抓取是否顺畅也會跟着變化。
為什么连接行為會影响抓取
HTTP/1.1 时代，一個连接同一时刻只能處理一個請求，蜘蛛要並發抓取就得開多條 TCP 连接。HTTP/2 之後，單條连接可以多路复用，多個請求並行在同一條连接上完成。两者對服務器资源的占用方式完全不同：前者消耗连接數和文件描述符，後者更依赖單连接的流處理與 CPU。
如果站点同时面對两類客戶端，只看“請求數”很难判断压力究竟来自哪里。
服務器侧能看到什么
- 活動连接數（ESTABLISHED 狀態）與来源 IP 分布
- 單 IP 的並發连接峰值，而不只是每分钟請求數
- 连接持續時間：是短连接频繁建立，還是長连接反复复用
- 协议版本：從日誌或抓包中区分 HTTP/1.1 與 HTTP/2
把這些指标和抓取日誌按時間對齐，才能看出蜘蛛的抓取是否被服務器侧的连接限制卡住。
Keep-Alive 與连接复用
Keep-Alive 让连接在多次請求之間保留，减少握手開销。對蜘蛛来说，复用连接意味着更稳定的抓取节奏；對服務器来说，長時間保持的空闲连接會占用资源。這里存在一個平衡点：超时設定太短，蜘蛛频繁重连，握手成本上升；設定太長，空闲连接堆积，遇到並發高峰时缺少余量。
注意区分“连接被服務器主動關閉”和“請求被拒绝”。前者通常表現為连接重置，後者是明确的 4xx 或 5xx，两者對抓取节奏的影响並不相同。
並發上限與限流配置
不少服務器或前置层會限制單 IP 的並發连接數。這個限制對 HTTP/1.1 蜘蛛影响明顯，因為它的並發直接体現為连接數；對 HTTP/2 蜘蛛影响相對小，连接數少，但單连接上的請求流可能很多。核對的顺序建议如下：
- 先確認蜘蛛使用的协议版本和實际並發连接數
- 再看限流規則是按连接數触發，還是按請求速率触發
- 對比触發限流的時間段與抓取日誌中的空档是否吻合
- 調整後观察抓取是否恢复，而不是只看請求數有没有變化
調整後的驗證方式
每次改動连接相關配置後，建议保持一段固定的观察期，用同一套指标對比改動前後：單位時間的成功抓取次數、连接重置次數、抓取空档时長。一次只改一個變量，结果才有參考價值。
常见的誤判
- 把连接數下降直接理解成抓取减少，忽略了 HTTP/2 复用後连接數本来就會變少
- 看到並發连接高就急着加机器，實际瓶颈可能是單连接的响應時間偏長
- 調整了限流阈值却没有留观察窗口，短期波動被当成了長期趋势
连接层面的信息不像狀態碼那样直观，但它能解释很多“抓取时好时坏”的現象。把连接指标和抓取日誌放在同一時間轴上看，判断會踏實很多，也更容易分清是站点承载問题，還是蜘蛛自身节奏變化。