蜘蛛池入口頁几乎没有真人訪問，訪客基本全是爬虫。把一批入口頁放出去之後，抓取往往不是均匀铺開的，而是在几個时段集中涌進来。這個时候决定站点稳不稳的，通常不是頁面内容寫得好不好，而是服務器愿意同时接住多少條连接、每條连接能撑多久。

為什么爬虫的连接是成批来的

爬虫按队列和批次推進抓取。一個入口域被识別之後，短時間内可能有多台机器從不同机房發起請求；同一台机器也會复用一條连接连續抓多個 URL。表現出来就是连接數在几分钟内陡增，随後回落。如果服務器按平均訪問量来配，尖峰阶段最容易出問题：排队變長、响應變慢，甚至直接拒绝新连接。

Keep-Alive 與连接复用怎么设

長连接的意义在于省掉重复的 TCP 和 TLS 握手。對蜘蛛池入口頁這類静態或半静態頁面，一次握手換多次抓取，收益比較明顯。但長连接開得太久也不好：空闲连接會占着 worker 名額，遇到突發並發时新請求反而排不上队。

几個值得調的參數

• keepalive_timeout：入口頁内容简單、响應快，可以设得短一些（几秒到十几秒），让空闲连接尽快释放给新請求。
• keepalive_requests：單條连接允许處理的請求數上限，设一個中等值，避免個別连接長期占用资源。
• worker 连接數：這是真正决定並發上限的地方，需要和机器内存、後端响應時間一起估算，而不是照搬模板。

需要注意，長连接是服務器侧的配置，爬虫是否复用由它自己决定，你只能提供條件，不能强制。

HTTP/2 與 HTTP/3 带来的變化

HTTP/2 在一條连接上多路复用多個請求，對入口頁這種小资源多的场景比較友好，连接數會明顯下降，但單條连接的内存開销會上升。HTTP/3 基于 UDP，弱網和跨机房的握手更快，不過並不是所有爬虫都會用。比較稳妥的做法是同时保留 HTTP/1.1 與 HTTP/2 的接入能力，不要只留一種。

並發上限该定多少

没有通用數字。可以用一個粗略方法估算：先用單請求平均响應時間乘以目标並發，得到大约需要的 worker 數量，再留出三成余量應對尖峰。入口頁如果是纯静態、能走缓存，並發可以给高一些；如果每個請求都要查库或走遠程接口，先把後端响應時間压下来，比單纯加连接數更有效。

超出上限时會發生什么

常见表現有三類：一是响應時間被拉長，抓取方等待超时；二是返回 5xx 或连接被重置；三是請求在队列里堆积，日誌里出現大量耗时很長的记錄。這三種情况如果反复出現在同一個入口域上，抓取频次通常會下降，恢复起来比較慢。宁可提前限流、明确返回 429 或 503 並带上 Retry-After，也比让請求卡住不放要好。

该長期盯哪些指标

• 同时活跃连接數，以及它的日内峰值出現在什么时段；
• 连接建立失敗率、請求超时率、5xx 占比；
• 各入口域的平均响應時間，看是否有單個域拖慢整体；
• 長连接的平均复用次數，判断 Keep-Alive 參數是否合理。

如果某個入口域的並發明顯高于其他域，先查它是不是被多個爬虫同时盯上，或者是不是代理层配置有差异，而不是直接给整台机器扩容。

几個常见誤区

• 把並發上限等同于带宽，實际上瓶颈经常在 worker 數量和後端响應時間上；
• 為了“接住更多蜘蛛”把超时時間調到很長，结果請求堆积，整体更慢；
• 只看带宽曲线，不看连接數曲线，尖峰問题在带宽上往往看不出来；
• 配置改完不做回归驗證，過几天尖峰来的时候才發現參數没生效。

入口頁的连接表現是蜘蛛池能否稳定运轉的基础之一。先把连接复用、並發上限和限流策略理清楚，再去讨论内容與連結结构，排查时會轻松很多。