讨论抓取预算时，容易只盯 URL 数量、内链和 Sitemap，却忽略一个更底层的变量：蜘蛛与服务器之间是怎么建立和复用连接的。同样的页面数量，连接层配置不同，抓取节奏可能差出数倍。这一层不直接决定收录，但会明显影响抓取效率与回访密度。
抓取是连接上的连续对话
蜘蛛抓取一批 URL 时，通常不是每个请求都重新做一次完整握手。它会尽量复用已有连接，按并发窗口持续发送请求。如果连接建立成本高、复用被中断，或者服务器对单一来源 IP 的并发连接有限制，蜘蛛就会在“等待连接”上消耗时间，而不是在“传输 HTML”上。表现出来就是日志里请求时间跨度被拉长，抓取频次看起来没有下降，但实际完成量变少。
三个容易被忽略的连接层变量
1. Keep-Alive 与连接关闭策略
服务器或中间层如果频繁主动关闭空闲连接，蜘蛛每次发请求都要重新握手，TLS 握手尤其昂贵。核对时看响应头里 Connection 的取值，以及日志中同一 IP 的请求是否呈现“短连接”特征。反向代理和负载均衡的健康检查、超时时间设置也可能误伤长连接。
2. HTTP/2 多路复用与并发流
HTTP/2 允许在一条连接上并行多个请求，理论上对抓取更友好，但前提是服务器正确启用且没有把并发流限制得过低。若 HTTP/2 协商失败退回 HTTP/1.1，抓取端会退回到每个域名 6 个左右并发连接的旧模式。核对时确认 ALPN 协商结果、TLS 版本，以及是否因为某个中间节点不支持而静默降级。
3. 服务器端并发与限流
应用服务器、WAF 或 CDN 可能对单 IP 并发连接数、每秒请求数设限，超出后返回 429、503 或直接重置连接。蜘蛛收到这类信号会退避，抓取节奏自然放缓。核对时把限流阈值与蜘蛛实际并发做对照，而不是只看平均 QPS。
核对顺序建议
- 先用日志按 IP 和 UA 聚合，看单次抓取会话的连接数、请求间隔和状态码分布。
- 检查响应头中的 Connection、Keep-Alive、Server、Via 等字段，判断连接是否被中间层改写。
- 用 curl 或类似工具观察 ALPN 与 HTTP 版本协商结果，确认没有静默降级。
- 对照 CDN、WAF、负载均衡的并发与限流配置，确认蜘蛛不在被限制的范围内。
- 若发现连接层问题，优先调整超时和限流参数，再观察抓取完成量是否变化。
连接层不会让内容变得更好，但它决定了内容有没有被及时取走。
常见误判
- 把抓取变慢直接归因于内容质量，忽略连接被限流。
- 只看平均响应时间，不看连接建立耗时和并发完成量。
- HTTP/2 已开启就默认生效，不检查协商是否降级。
- 调整限流后立刻期待抓取量上升，忽略蜘蛛自身调度周期。
连接复用、并发上限和限流策略属于基础设施层，调整起来通常比改模板更快。建议每次改完只动一个变量，用日志里的完成量而不是主观感受来判断效果。抓取节奏的改善往往是渐进的，需要一段时间观察。