很多人把蜘蛛想象成一条一条顺序访问的爬虫，实际上抓取端会同时对同一个站点保持若干条并发连接。同一时间能开多少条，既取决于抓取端对“每个主机”的并发上限，也取决于服务器能不能稳稳接住这些连接。
并发是一条“每主机”的配额
抓取端通常按主机名来限制并发，有时也按 IP 或整个站点。粒度不同，结果就不同：如果按域名限制，www 与 m 会被当成两个主机分别拿到配额；如果按 IP，同一台服务器上的多个子域会共享配额。这也能解释为什么多站点部署在同一 IP 上时，日志里的抓取密度看起来比单站更集中。
连接复用比并发数更影响效率
keep-alive 与握手开销
一次完整请求要经历 DNS、TCP、TLS（HTTPS 场景）几轮往返。如果服务器响应后立刻关闭连接，蜘蛛每次都得重走一遍握手，抓同样数量的 URL 会消耗更多时间。开启 keep-alive、把 Keep-Alive timeout 设置在合理区间，让一条连接承载多次请求，对抓取端和服务器都更省。
HTTP/2 的多路复用
HTTP/2 允许在一条连接上并行传输多个请求，抓取端可以用更少的连接完成更多请求。前提是服务端确实启用了 HTTP/2，并且没有在中间层被降级。如果 CDN 或负载均衡把协议改写回 HTTP/1.1，多路复用就不存在了，抓取端只能靠增加连接数来补，服务器压力也随之上升。
服务器端连接不够用时会怎样
Web 服务都有并发处理上限，比如工作进程数、线程数或连接池大小。当蜘蛛的并发加上真实用户把连接占满，超出部分一般有两种结果：一是排队等待，响应时间被拉长；二是直接拒绝或重置连接。前者会让蜘蛛感知为“慢”，后者更容易被当成临时故障。无论哪种，抓取速度都会降下来，甚至触发抓取端主动退避。
慢请求会一直占着连接
如果某个动态接口要几秒才返回，它会持续占用一条连接。蜘蛛并发本来就只有几条，其中一条被卡住，整体吞吐就会明显下降。这也是列表页、站内搜索这类重查询页面，往往比静态内容页更“拖后腿”的原因。
从日志看并发是否成为瓶颈
- 同一 IP 的记录密集出现在同一秒，说明并发确实在生效；
- 大量连接被重置、出现 499 或 502，通常是服务端先撑不住；
- 响应时间集中在几百毫秒以上，且与抓取时段重合，说明处理能力接近上限；
- 同一 URL 短时间内被反复请求，可能是上一次请求被中断后重试。
可以做的几件事
- 确认 keep-alive 与 HTTP/2 已生效，减少重复握手；
- 给动态接口设置合理的超时与缓存，别让它长时间占用连接；
- 监控抓取高峰时段的响应时间与错误率，而不是只看全天平均值；
- 服务器承载有限时，优先保证内容页可访问，功能页可以慢一些；
- 把抓取日志与服务器监控对照看，区分“蜘蛛不来”和“来了但接不住”。
并发不是越高越好。抓取端会自己控制节奏，站点真正该关心的是：在自己的承载范围内，把稳定、快速的响应留给那些需要被发现和抓取的 URL。