很多站点在日誌里看到蜘蛛的請求，會預設以為它是沿着队列一條一條慢慢爬。實际情况通常不是這样：搜尋引擎的抓取端會针對一個站点同时開啟若干條连接，把队列里的 URL 並行取回。理解這一点，對判断服務器压力和排查抓取變慢的原因都有帮助。
蜘蛛不是只開一條连接
抓取端會根據站点的整体表現来分配並發規模。响應快、错誤率低的站点，往往會被允许更多连接同时進来；反過来，如果超时频繁、5xx 較多，並發會被收缩，抓取速度随之下降。也就是说，並發數不是固定的福利，更像是站点健康度的一個反馈结果。
並發數是怎么變成服務器压力的
可以用一個粗略的換算来理解：並發數乘以單頁處理時間，大致對應每秒的請求量。假设蜘蛛在站上维持 5 條並發，每個頁面處理 200 毫秒，那么大约是每秒 25 個請求；如果每頁要處理 2 秒，每秒只剩 2.5 個請求。有意思的是，後一種情况下服務器虽然被拖慢，蜘蛛抓到的頁面反而更少——响應慢並不等于压力小，只是把压力拉長了。
响應變慢之後，抓取节奏會怎么變
單頁變慢时，通常先看到的是抓取速率下降，队列里的 URL 等待時間變長。如果慢到触發超时，蜘蛛會中断這次請求，稍後再来；少數几個超时影响不大，但如果超时變成常態，抓取端可能會主動降低並發，甚至把站点标记為慢站，抓取频次随之减少。這個過程往往没有明顯提示，只能從日誌里的請求數和响應時間看出来。
服務器侧常见的几個坑
- 單頁處理時間随並發线性上涨：資料库连接池不够、同步調外部接口，都會让並發一上来就集体變慢。
- 没有開啟長连接：每個請求都重新握手，连接開销吃掉大量资源。
- CDN 或 WAF 把蜘蛛的多條连接当成異常流量，返回 403 或驗證碼，抓取直接中断。
- 服務端渲染的逻辑在請求内同步执行，遇到並發就大面积超时。
- 抓取高峰與真實用戶高峰重叠，两邊互相拖慢，谁都不满意。
可以做的几件事
- 在日誌里按分钟統計蜘蛛請求數，先看清峰值是多少，而不是只看一天的總量。
- 给重要目錄單獨观察响應時間，先把慢的模板或接口優化掉。
- 让頁面主体和静態资源分開處理，避免一個慢接口拖住整個頁面的返回。
- 核對 CDN 與 WAF 的爬虫放行規則，確認放行的是真實蜘蛛的 IP 段。
- 服務器确實扛不住时，用 503 配合 Retry-After 明确告知，比让請求挂到超时更友好。
抓取並發更像是结果而不是原因：站点响應越快、错誤越少，蜘蛛越敢多開连接。想把抓取做好，先把單頁响應時間和错誤率降下来，再谈其他。