蜘蛛池跑到一定規模，最容易被忽略的問题不是“蜘蛛来不来”，而是“蜘蛛一次来太多”。几十上百個入口頁如果在同一時間段被抓，請求會集中打到同一台服務器、同一個 IP 段，這时候頁面本身没問题，服務器先撑不住了。
蜘蛛的抓取從来不是均匀的
新入口頁刚被發現、站点地图刚更新、内鏈刚調整，都可能引来一波集中抓取。加上不少蜘蛛會並發請求，同一個 IP 上短時間内出現几百個连接並不罕见。如果平时按平均 QPS 配资源，洪峰一来就會超时、丢包，甚至整台机器無响應。
更麻烦的是，服務器被打满之後，蜘蛛拿到的可能是超时或 5xx。连错几次，它通常會主動降低對你這個站点的抓取频率，恢复起来比掉一次抓取更慢。
先分清是“慢”還是“不够用”
- 带宽或 CPU 打满：多項监控同时飙高，日誌里大量請求耗时相近且都變長。
- 连接數被占满：Web 服務進程數或最大连接數到顶，新請求排队等待。
- 蜘蛛自己降速：服務器很闲，但此前返回過太多 5xx 或超时，蜘蛛主動减少了並發。
這三種情况的處理方式完全不同，先看监控和日誌再動手，別一上来就加机器。
限速要按来源分開做
- 按 IP 和 UA 分组統計，把已知蜘蛛、来源不明的高频請求、普通訪客区分開，分別设阈值。
- 對已知搜尋引擎蜘蛛给相對宽松的額度，避免誤伤；對来源不明的高频請求收紧。
- 返回 429 时带上 Retry-After，告诉對方多久後再来，比直接断開连接更友好。
- 控制單 IP 的並發连接數，而不是只看每秒請求數，長连接场景下並發數更關键。
- 在 CDN 或反向代理层做第一道限速，源站再做一道兜底。
別把真蜘蛛一起挡在门外
限速規則寫得太粗，最容易出現的後果是：正常蜘蛛被挡，伪装爬虫照样進来。判断来源不能只看 UA 字符串，UA 可以随便寫。更稳的做法是结合反向解析、IP 段归属和訪問行為一起看。
如果實在拿不准，宁可對已知蜘蛛放行、對未知来源限速，也不要一刀切。挡住真蜘蛛的代價，往往比多扛一点流量更高。
容量按什么口径估
- 看歷史日誌里的峰值並發，而不是平均值，按峰值再留一点余量。
- 入口頁越轻越好：静態化、少查库、少調外部接口，單請求成本降下来，同样配置能扛的並發就上去了。
- 把入口頁分散到不同 IP、不同机器上，通常比把單机配置堆高更有效。
- 分批放量：新入口頁不要一次性全部提交，按批次上线，观察日誌再推下一批。
上线之後看什么
限速規則不是设完就不用管。每周至少看一次：429 和 503 的返回比例、蜘蛛請求的响應時間分布、被限速的 IP 里有多少是已知蜘蛛。如果已知蜘蛛频繁被限，說明阈值太紧；如果服務器依然被打满而限速没触發，說明規則没覆盖到那類来源。
把“蜘蛛洪峰”当成常態来准备，入口頁的稳定性會比事後救火好很多。