谈抓取时，多数人先看内容质量和入口数量，但还有一个容易被忽略的层面：连接。蜘蛛在单位时间内能发出多少请求，不只取决于服务器处理速度，也取决于连接是否被复用。同一台服务器，内容完全一样，连接配置不同，抓取表现可能差出一截。
连接复用为什么会改变抓取节律
在 HTTP/1.1 下，一个请求通常对应一条 TCP 连接。如果服务端愿意保持连接，蜘蛛可以在同一条连接上连续请求多个 URL，省掉反复的握手开销；如果服务端每次都返回 Connection: close，或者把 keep-alive 超时设得很短，蜘蛛就得不断新建连接、重新握手，单位时间内能完成的请求自然变少。
更隐蔽的情况是负载均衡：同一只蜘蛛的请求被分散到不同后端节点，各自维护连接，看起来连接数不少，实际可复用的会话很少。
几个可以直接检查的点
- 看响应头里是否存在 Connection: close，或者 keep-alive 的超时时间是否明显偏短。
- 看 TLS 握手次数与请求数的比例，比例接近一比一，说明连接几乎没被复用。
- 看负载均衡是否开启了会话保持，以及空闲连接被回收的时间。
- 看访问日志里同一来源 IP 的连接持续时间分布，判断是长连接还是频繁短连接。
HTTP/2 带来的变化与新的盲区
启用 HTTP/2 后，多条请求可以共用一条连接，服务端看到的并发从“连接数”变成了“流数”。好处是握手成本下降、抓取节律更平稳；但也会带来新的观察盲区：只看连接数的监控会显示得很平静，实际单条连接上可能积压了大量请求。
另一种情况是流控窗口设置过小，或者后端某个接口排队，导致个别流迟迟拿不到响应。蜘蛛侧看到的是请求超时或迟迟不返回，而服务器整体负载并不高。排查时需要把流级别的等待时间单独拉出来看，而不是只看 CPU 和带宽。
观测指标建议
- 单位时间抓取请求数：按小时统计，观察调整前后的变化趋势。
- 平均连接持续时间：过短说明复用不足，过长要确认是否有请求卡住。
- 握手次数与请求数之比：越低说明复用越好。
- 超时与重试比例：与连接层指标放在同一张图上对照。
连接层调整只影响抓取过程的顺畅程度，并不能决定页面是否被收录或获得排名，把两者混为一谈容易做出错误决策。
落地顺序
- 先确认现状：抓一份包含连接信息的抓取日志样本，作为基线。
- 调整 keep-alive 超时与单连接最大请求数，幅度不要太大，一次只改一个参数。
- 确认 HTTP/2 或 HTTP/3 的启用范围，注意部分老旧中间件对多路复用的支持并不完整。
- 调整后观察一到两周，重点看抓取请求数与超时率的曲线，而不是某一天的数字。
连接层的问题往往不显眼，但它决定了同样的内容、同样的入口，蜘蛛能不能在同样的时间里走完。把它和 URL 发现、内链路径放在一起看，排查思路会更完整。