先分清限速和拦截是两回事
不少人在服務器上看到蜘蛛請求量上来，第一反應是加限速規則，结果發現訪問量直接掉下去。原因往往是把限速寫成了拒绝：請求間隔稍短就返回 429 或直接断開连接，蜘蛛几次不成功之後會降低對整站的抓取频率。限速的目的是削峰，让並發落在服務器能稳定响應的区間，而不是制造失敗請求。
三個需要先量出来的數值
- 單 IP 的並發连接數：同一只蜘蛛可能同时開多條连接，观察日誌里同一 IP 在同一秒内出現的請求條數。
- 請求間隔分布：多數正常抓取會保持一個大致稳定的間隔，突發的密集請求需要單獨拿出来看。
- 單個頁面的响應体积：入口頁返回越大，同样的並發下占用的带宽越高，超时也越容易發生。
這三個數值不需要精确到小數点，取一周日誌做個粗略分布就够用了。關键是有據可依，而不是凭感觉拍阈值。
常见的限速寫法與适用场景
按並發连接數限制
Nginx 的 limit_conn 适合控制同一 IP 同时占用的连接數。它不限制請求频率，只限制同时被處理的數量，對防止個別 IP 把连接池占满比較有效。
按請求速率限制
limit_req 以漏桶方式控制每秒請求數。這里的 rate 和 burst 需要留出余量，burst 太小會把正常波動也判成超限。触發限速後建议返回 429，而不是 403 或直接 reset，让蜘蛛知道這是临时狀態而非頁面不存在。
整站层面的出口带宽
如果入口頁体积偏大，带宽瓶颈往往先于 CPU 出現。這種情况下與其繼續加限速，不如先做頁面压缩、合並或去掉不必要的资源引用，把單次請求的成本降下来。
什么时候该放宽，什么时候该收紧
- 蜘蛛請求成功率長期在 99% 以上、响應時間平稳：不必額外限速。
- 日誌里出現成片的 5xx 或超时：先查服務器负载、資料库和磁盘，再考虑限速。
- 單個 IP 短時間内請求量明顯高于其他 IP：可以對该 IP 單獨设一條更嚴的規則，而不是全站收紧。
- 带宽或连接數经常打满：先做连接數限制，再评估要不要扩容。
調整时看哪几個指标
調整前後至少對比三样東西：蜘蛛請求的成功率、平均响應時間、單位時間内的請求條數。三個指标一起看，才能判断限速是削掉了峰值，還是把正常抓取也一起削掉了。每次只改一個參數，观察一到两天再决定下一步，避免多個變量同时變化後無法归因。
限速規則的目标是让抓取過程保持连續、可预期，而不是把流量压到最低。參數越嚴並不等于越安全，失敗請求堆积反而會让蜘蛛减少来訪。
几條落地建议
- 先记錄一周的原始日誌，再决定阈值，不要凭感觉拍數字。
- 對已知蜘蛛的 UA 與其 IP 段單獨建規則，與普通訪客区分開。
- 限速触發後返回 429，並尽量保留连接复用，减少握手開销。
- 每次調整後回看日誌，確認没有出現新的失敗類型。
- 限速規則本身也要留档，寫清改了什么、為什么改、改完观察到的结果。