在日誌里，抓取节奏常常並不均匀：有时几分钟内涌進一大批請求，有时又長時間没有動静。遇到這種情况，多數人會先去检查内容更新频率或抓取退避策略，但服務器侧的连接處理方式同样是一個容易被忽略的變量。连接复用是否顺畅、並發上限卡在哪一层，會直接影响蜘蛛在一次會话里能带走多少 URL。
连接复用决定了單次會话的效率
蜘蛛在訪問一個站点时，通常不會為每個 URL 都重新建立连接。它會在一條長连接上连續發送多個請求，省掉重复的 TCP 與 TLS 握手。如果這條连接在很短時間内被服務端關閉，蜘蛛就只能反复重建连接，抓取速率随之下降，握手本身還會額外消耗 CPU 和带宽。
几個常见的長连接問题
- 响應头中明确返回 Connection: close，導致每個請求都變成一次新的连接。
- 反向代理或應用服務器的 keepalive 超时設定過短，比如只有 1 到 2 秒。
- 负载均衡未開啟连接复用，回源时每次都新建连接。
- HTTP/2 下最大並發流數設定偏小，多個請求在一條连接上排队等待。
协议版本带来的差异
HTTP/1.1 时代，蜘蛛往往通過多條並行连接提升吞吐；HTTP/2 則倾向于在一條连接上多路复用。两者本身没有優劣，關键是服務端的配置要和實际流量匹配。如果開啟了 HTTP/2，却把並發流限制得很低，效果可能還不如老协议。
並發上限究竟卡在哪一层
抓取量上不去，很多时候並不是蜘蛛不愿抓，而是在某一层被限住了。按從外到内的顺序，常见的有以下几處：
- 單 IP 並發连接數限制，可能是防火墙或安全组层面的。
- WAF 或防爬组件的频率限制，短時間内触發後返回 429 或 503。
- CDN 的回源並發與连接池大小。
- 應用服務器的线程池或工作進程數。
- 資料库连接池或下游接口的响應能力。
這几层中，任何一层先到瓶颈，都會表現為抓取节奏變慢，但日誌里看到的現象可能完全不同：有的是连接被重置，有的是响應變長，有的干脆没有請求到達應用层。
一套可落地的排查顺序
建议按下面几步走，尽量每次只調整一個變量，避免互相干扰。
- 按 IP 與 User-Agent 分组統計請求，观察單 IP 的並發峰值和請求間隔分布。
- 查看响應头里的协议版本、Keep-Alive 參數以及是否出現 Connection: close。
- 把 429、503、连接重置的時間点與並發曲线對齐，判断是限流還是资源不足。
- 對比直连源站與经過 CDN 时的表現，定位瓶颈所在层級。
- 检查反向代理與應用的 keepalive 超时、最大连接數、线程池配置是否明顯偏小。
- 調整後固定一個观察窗口，记錄同一时段的抓取條數與平均响應時間。
調整时值得注意的几点
- keepalive 超时不必一味拉長，5 到 15 秒通常是較稳妥的区間，過長會占用连接资源。
- 针對已確認身份的蜘蛛，尽量避免使用與其他訪客相同的激進频控策略。
- 開啟 HTTP/2 後，留意並發流與窗口大小是否符合服務器實际承载力。
- CDN 侧的回源连接池要與源站承受能力匹配，避免回源洪峰。
需要提醒的是，抓取量增加並不等于收錄或排名提升。把连接和並發調顺，只是让已有的優质 URL 更容易被發現，站点内容质量與结构仍是基础。
观察窗口與常见誤区
连接层面的調整，效果通常不會立刻顯現。建议至少观察一周，並留意抓取分布是否更均衡，而不是只看某一天的總量。另一個常见誤区是把抓取波動全部归因于服務器：如果站点近期大量新增或删改 URL，节奏變化也可能来自抓取侧的重新评估。排查时把服務端指标與内容變更记錄放在一起看，结论會更可靠。