搭蜘蛛池时，多數人把精力放在入口頁的内容、連結和模板上，服務器這一层往往按“能打開就行”来配置。等到蜘蛛開始密集回訪，入口頁出現零星 502、超时或连接被重置，抓取量就悄悄掉下来了。這篇從並發连接的角度，说说入口頁服務器该怎么看、怎么調。
並發连接數指的是什么
蜘蛛抓取不是一次一個請求。同一個蜘蛛在短時間内會對你的站点開多條连接，同时把多個 URL 排進队列。服務器侧的並發，通常包含几层含义：
- 單 IP 並發：同一個蜘蛛 IP 同时建立的连接數；
- 站点總並發：所有来源的活跃請求之和；
- 连接复用：開啟 keep-alive 後，一條 TCP 连接可以承载多個請求，實际並發压力會低于請求數；
- HTTP/2 多路复用：同一连接上並行多個請求，连接數下降，但單连接的资源占用上升。
搞清這几层，才能判断“並發高”是真高，還是只是請求數看起来多。
蜘蛛端自己會控速
主流搜尋引擎的抓取程序都有速率控制，會參考你站点的响應時間、错誤率、頁面体积来動態調整。响應稳定、错誤率低，抓取节奏會慢慢放開；反之，它會主動降低频率。
慢响應和 5xx 是天然的降速信号。蜘蛛池里少抓几次的代價往往比想象中大，因為恢复需要時間。
服務器扛不住时的典型表現
- 訪問日誌里出現集中的 502、504，或连接被 reset；
- TTFB 從几十毫秒拉到一两秒，且集中在某些时段；
- 同一入口頁反复被重试，日誌里同一 URL 短時間多次出現；
- 部分入口頁長期没有蜘蛛訪問，像是“被跳過”；
- 服務器负载不高，但连接數打满，新請求開始排队。
注意最後一條：CPU 和内存看起来還好，不代表没問题，连接數和文件描述符上限先到，同样會拒绝新請求。
排查顺序
- 先看訪問日誌與错誤日誌，確認是哪些入口頁、哪個时段、哪種狀態碼出問题；
- 確認入口頁是不是動態生成，有没有資料库查询或遠程調用拖慢响應；
- 检查 nginx/Apache 的 worker 數量、连接數上限、文件描述符上限；
- 確認是否有 CDN 或 WAF 在中間，誤伤和回源压力要分開看；
- 最後才考虑限流，限流規則要放行已知蜘蛛 UA 與 IP 段。
顺序颠倒容易白忙：先加限流，可能把本来就正常的蜘蛛一並挡掉。
常用的調參手段
- 静態化與缓存：入口頁内容變化不频繁时，生成静態文件或加短周期缓存，是最直接的一步；
- 精简頁面：去掉不必要的脚本、大图、外部統計，减少连接占用與带宽；
- keep-alive 超时：适当保留复用，別為了“省连接”把超时調得過低；
- 分散承载：入口頁分散到不同域名、不同服務器或 CDN 邊缘，避免單点；
- 限流要谨慎：limit_conn、limit_req 可以救急，但要留白名單，否則容易誤伤蜘蛛。
带宽與容量估算的思路
入口頁平均体积 × 预期日抓取次數，大致就是日流量，再乘 3 到 5 倍留出峰值余量。共享虚拟主机、單核小机器跑几百上千個入口頁，通常不是“能不能打開”的問题，而是並發一来就排队。與其事後救火，不如一開始就把承载能力算進去。
几條使用建议
- 给入口頁加基础的可用性监控，狀態碼和响應時間異常要能第一時間看到；
- 新入口頁批量上线时先小規模观察，確認服務器吃得消再铺開；
- 不要用激進的限流把正常蜘蛛挡在门外，那等于自己關掉入口；
- 定期复查 CDN、WAF 與服務器三层的配置，避免規則叠加後互相冲突。
蜘蛛池解决的是 URL 發現和被抓取的机會，能不能持續被抓，取决于入口頁是否長期稳定可訪問。並發和连接數這件事不顯眼，但它决定了蜘蛛愿不愿意繼續来。