蜘蛛池入口页几乎没有真人访问，访客基本全是爬虫。把一批入口页放出去之后，抓取往往不是均匀铺开的，而是在几个时段集中涌进来。这个时候决定站点稳不稳的，通常不是页面内容写得好不好，而是服务器愿意同时接住多少条连接、每条连接能撑多久。

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

爬虫按队列和批次推进抓取。一个入口域被识别之后，短时间内可能有多台机器从不同机房发起请求；同一台机器也会复用一条连接连续抓多个 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 数量和后端响应时间上；
• 为了“接住更多蜘蛛”把超时时间调到很长，结果请求堆积，整体更慢；
• 只看带宽曲线，不看连接数曲线，尖峰问题在带宽上往往看不出来；
• 配置改完不做回归验证，过几天尖峰来的时候才发现参数没生效。

入口页的连接表现是蜘蛛池能否稳定运转的基础之一。先把连接复用、并发上限和限流策略理清楚，再去讨论内容与链接结构，排查时会轻松很多。