先分清限速和拦截是两回事
不少人在服务器上看到蜘蛛请求量上来，第一反应是加限速规则，结果发现访问量直接掉下去。原因往往是把限速写成了拒绝：请求间隔稍短就返回 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，并尽量保留连接复用，减少握手开销。
- 每次调整后回看日志，确认没有出现新的失败类型。
- 限速规则本身也要留档，写清改了什么、为什么改、改完观察到的结果。