Nginx并发限制无万能阈值，需分层测算：先按CPU核数设worker_processes为auto，调高worker_connections并同步提升系统文件描述符；再依业务区分limit_conn（控连接数，如单IP 50～100）与limit_req（控QPS，rate基于95分位RPS×1.5～2，burst=rate×容忍秒数）；最后必须干跑验证、429日志监控、灰度上线。
评估并设置 Nginx 并发限制的最佳实践阈值，核心不是找一个“万能数字”，而是基于真实服务特征、系统资源和业务容忍度做分层测算与验证。关键要区分清楚：你真正想控的是“并发连接数”（limit_conn），还是“单位时间请求数”（limit_req），两者目标不同、配置逻辑也不同。
先看硬件与内核承载上限
这是所有限流的物理天花板。不摸清这个，上层策略就是空中楼阁：
-
worker 进程数建议设为
auto，让 Nginx 自动匹配 CPU 核心数（如 8 核服务器默认启 8 个 worker） -
单 worker 最大连接数（
worker_connections）需同步调高，常见值有 16384 或 65535；但必须配套调整系统级文件描述符限制：
→ 临时：运行ulimit -n 65535
→ 永久：在/etc/security/limits.conf中添加* soft nofile 65535和* hard nofile 65535 - 理论最大并发连接数 = worker_processes × worker_connections，比如 8 × 16384 = 131072 —— 这是连接保活能力的上限，不代表它能稳定处理同等 QPS
再按业务场景定连接数限制（limit_conn）
适用于控制瞬时资源占用，比如防爬虫建大量空闲长连接、保护后端数据库连接池：
- 对普通 Web 用户，单 IP 限 50～100 并发连接已足够（浏览器通常最多开 6～8 个 TCP 连接）
- 对 API 客户端，若使用 HTTP/2 或长连接，可适当放宽到 200～500，但需结合后端实际吞吐反推
- 敏感路径（如登录、支付回调）建议单独设更严策略，例如
limit_conn conn_limit 10 - 内存开销要注意：
zone=conn_limit:10m在 64 位系统约支持 8 万个客户端状态，IP 越多、越需扩大 zone 大小
然后按流量特征定请求速率限制（limit_req）
这是最常用、也最容易误配的一层，重点在 rate + burst 的组合设计：
-
rate 值不能拍脑袋定：先用真实日志统计某接口 95 分位的每秒请求数（RPS），再乘以 1.5～2 倍作为初始
rate。例如日志显示峰值 RPS 是 80，则从rate=120r/s开始试 -
burst 缓冲区大小 = rate × 期望容忍的突发秒数。比如允许用户快速刷新 3 秒内的请求，burst 就设为
360（120×3）；但 burst 过大会削弱限流效果，一般不超过 rate 的 3～5 倍 - 加
nodelay表示突发请求不排队、直接通过（模拟令牌桶），适合用户体验优先的场景；不加则按漏桶匀速放行，更适合严格保护后端 - 务必用
$binary_remote_addr作 key，比$remote_addr更省内存，尤其 IPv6 环境下明显
最后必须做的三件事
再好的阈值，不验证、不监控、不灰度，等于没设：
- 上线前用
limit_req_dry_run on（Nginx ≥1.17.1）开启干跑模式，只统计不限制，观察实际命中率是否合理 - 把限流拒绝日志单独归类，例如
limit_req_log_level warn，配合limit_req_status 429（而非默认 503），方便前端识别和重试 - 首次上线不要全量，先对灰度流量（如特定 header 或 UA）启用，确认不影响核心转化路径后再扩至全量
