在日志里，抓取节奏常常并不均匀：有时几分钟内涌进一大批请求，有时又长时间没有动静。遇到这种情况，多数人会先去检查内容更新频率或抓取退避策略，但服务器侧的连接处理方式同样是一个容易被忽略的变量。连接复用是否顺畅、并发上限卡在哪一层，会直接影响蜘蛛在一次会话里能带走多少 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，节奏变化也可能来自抓取侧的重新评估。排查时把服务端指标与内容变更记录放在一起看，结论会更可靠。