经常有人问：蜘蛛一次会发多少个请求？其实没有一个固定数字。它更像是蜘蛛根据站点过去的响应表现，动态调整出来的并发规模。理解这一点，比记住某个具体数值更有用。
并发是结果，不是设定
蜘蛛调度器会综合几件事，来决定对某个主机同时开多少条请求：
- 站点历史响应速度：过去返回得快、错误少，通常愿意多派一些请求过来；
- 服务器错误比例：5xx 或连接超时增多时，并发会主动收缩；
- 抓取预算与站点规模：大站和小站的调度节奏本来就不同；
- URL 的更新频率与重要性信号：来自 Sitemap、内链、主动提交的地址会影响先后顺序；
- 主机是否稳定：连接经常被重置、证书异常，容易被降速甚至暂时搁置。
所以“蜘蛛并发数”是一个动态值，而不是配置文件里的常量。
HTTP/1.1 与 HTTP/2 的实际差别
在 HTTP/1.1 下，一条连接同一时间只能处理一个请求，浏览器和蜘蛛都要靠多开连接来并行；连接数一多，握手、TLS 协商、排队等待的成本都会上来。HTTP/2 支持在一条连接上多路复用多个请求，同样的抓取量，连接数通常更少，握手开销也更低。
不必为了蜘蛛单独去改协议。如果站点本来就跑在 HTTP/2 或 HTTP/3 上，蜘蛛抓取时也能享受同样的连接复用，这对并发抓取是顺带的好处。
keep-alive：别让每条请求都重新握手
连接复用依赖 keep-alive。如果源站或中间层把连接超时设得很短，蜘蛛每个请求都要重新建立连接，抓取效率会明显下降，日志里往往表现为大量连接建立、响应时间忽长忽短。检查反向代理、负载均衡和 CDN 的 keep-alive 超时，让它们保持合理且一致即可，不建议为了抓取刻意设得特别长。
抓取压力最终落在哪里
并发上来之后，压力通常不是均匀分布的：
- 动态页面：每次抓取都可能触发数据库查询和模板渲染；
- 列表页与筛选页：分页、排序、组合参数会把单次请求成本放大；
- 静态资源：CSS、JS、图片被一并抓取时，带宽占用往往比 HTML 更明显；
- CDN 回源：缓存命中率低时，蜘蛛的请求会穿透到源站。
很多人只盯着 HTML 的每秒请求数，却忽略了同一时间还在被抓的还有一批静态资源，源站压力自然比预期高。
在日志里怎么看并发
- 按秒对日志分组，只统计已知蜘蛛的 User-Agent 与 IP 段；
- 看同一秒内来自同一主机的请求条数，再结合每条请求的响应耗时；
- 区分静态资源与 HTML，别把资源请求算进页面抓取的并发；
- 把并发曲线和响应时间、5xx 数量放在一起对照，看哪个先变化。
需要注意，同一秒出现多条请求，也可能来自不同 IP 的分布式抓取，不要简单等同于“蜘蛛并发提升了”。
想提升有效抓取，先降低单次请求成本
- 给不常变化的页面配好缓存头，减少回源；
- 简化重定向链，一次跳转就意味着多一次往返；
- 开启压缩，减小传输体积；
- 把渲染依赖的第三方脚本收窄到必要范围，避免渲染抓取长时间等待。
单次请求便宜了，同样的并发能覆盖更多 URL，这比单纯盼着蜘蛛多开连接更可控。
什么时候该主动限速
如果源站在某些时段本身就吃紧，与其等蜘蛛超时后自行降速，不如主动留出缓冲：用 429 或 503 配合 Retry-After 让它稍后再来，比直接封 IP 段更温和，也不容易误伤正常访问。robots.txt 里的 crawl-delay 只被部分蜘蛛支持，不适合当作通用方案。
并发只是表象。真正决定抓取节奏的，是每一次请求有多便宜、服务器有多稳。