很多人把蜘蛛想象成一條一條顺序訪問的爬虫，實际上抓取端會同时對同一個站点保持若干條並發连接。同一時間能開多少條，既取决于抓取端對“每個主机”的並發上限，也取决于服務器能不能稳稳接住這些连接。
並發是一條“每主机”的配額
抓取端通常按主机名来限制並發，有时也按 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。