抓取日志里看到的请求数只是结果，背后还有一层常被忽略的东西：蜘蛛是用多少条连接、以什么方式把这些请求送到服务器上的。同样的抓取量，连接行为不同，服务器感受到的压力差别很大，抓取是否顺畅也会跟着变化。
为什么连接行为会影响抓取
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 复用后连接数本来就会变少
- 看到并发连接高就急着加机器，实际瓶颈可能是单连接的响应时间偏长
- 调整了限流阈值却没有留观察窗口，短期波动被当成了长期趋势
连接层面的信息不像状态码那样直观，但它能解释很多“抓取时好时坏”的现象。把连接指标和抓取日志放在同一时间轴上看，判断会踏实很多，也更容易分清是站点承载问题，还是蜘蛛自身节奏变化。