经常有人問：蜘蛛一次會發多少個請求？其實没有一個固定數字。它更像是蜘蛛根據站点過去的响應表現，動態調整出来的並發規模。理解這一点，比记住某個具体數值更有用。
並發是结果，不是设定
蜘蛛調度器會综合几件事，来决定對某個主机同时開多少條請求：
- 站点歷史响應速度：過去返回得快、错誤少，通常愿意多派一些請求過来；
- 服務器错誤比例：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 只被部分蜘蛛支持，不适合当作通用方案。
並發只是表象。真正决定抓取节奏的，是每一次請求有多便宜、服務器有多稳。