蜘蛛池跑到一定规模，最容易被忽略的问题不是“蜘蛛来不来”，而是“蜘蛛一次来太多”。几十上百个入口页如果在同一时间段被抓，请求会集中打到同一台服务器、同一个 IP 段，这时候页面本身没问题，服务器先撑不住了。

蜘蛛的抓取从来不是均匀的

新入口页刚被发现、站点地图刚更新、内链刚调整，都可能引来一波集中抓取。加上不少蜘蛛会并发请求，同一个 IP 上短时间内出现几百个连接并不罕见。如果平时按平均 QPS 配资源，洪峰一来就会超时、丢包，甚至整台机器无响应。

更麻烦的是，服务器被打满之后，蜘蛛拿到的可能是超时或 5xx。连错几次，它通常会主动降低对你这个站点的抓取频率，恢复起来比掉一次抓取更慢。

先分清是“慢”还是“不够用”

• 带宽或 CPU 打满：多项监控同时飙高，日志里大量请求耗时相近且都变长。
• 连接数被占满：Web 服务进程数或最大连接数到顶，新请求排队等待。
• 蜘蛛自己降速：服务器很闲，但此前返回过太多 5xx 或超时，蜘蛛主动减少了并发。

这三种情况的处理方式完全不同，先看监控和日志再动手，别一上来就加机器。

限速要按来源分开做

1. 按 IP 和 UA 分组统计，把已知蜘蛛、来源不明的高频请求、普通访客区分开，分别设阈值。
2. 对已知搜索引擎蜘蛛给相对宽松的额度，避免误伤；对来源不明的高频请求收紧。
3. 返回 429 时带上 Retry-After，告诉对方多久后再来，比直接断开连接更友好。
4. 控制单 IP 的并发连接数，而不是只看每秒请求数，长连接场景下并发数更关键。
5. 在 CDN 或反向代理层做第一道限速，源站再做一道兜底。

别把真蜘蛛一起挡在门外

限速规则写得太粗，最容易出现的后果是：正常蜘蛛被挡，伪装爬虫照样进来。判断来源不能只看 UA 字符串，UA 可以随便写。更稳的做法是结合反向解析、IP 段归属和访问行为一起看。

如果实在拿不准，宁可对已知蜘蛛放行、对未知来源限速，也不要一刀切。挡住真蜘蛛的代价，往往比多扛一点流量更高。

容量按什么口径估

• 看历史日志里的峰值并发，而不是平均值，按峰值再留一点余量。
• 入口页越轻越好：静态化、少查库、少调外部接口，单请求成本降下来，同样配置能扛的并发就上去了。
• 把入口页分散到不同 IP、不同机器上，通常比把单机配置堆高更有效。
• 分批放量：新入口页不要一次性全部提交，按批次上线，观察日志再推下一批。

上线之后看什么

限速规则不是设完就不用管。每周至少看一次：429 和 503 的返回比例、蜘蛛请求的响应时间分布、被限速的 IP 里有多少是已知蜘蛛。如果已知蜘蛛频繁被限，说明阈值太紧；如果服务器依然被打满而限速没触发，说明规则没覆盖到那类来源。

把“蜘蛛洪峰”当成常态来准备，入口页的稳定性会比事后救火好很多。