max_conns 仅在满足三前提时有效：Nginx≥1.11.5、upstream用least_conn或ip_hash、至少两台server；需结合keepalive、queue排队及压测验证，数值须依后端真实承载力设定。
必须满足的三个硬性前提
缺一不可，否则 `max_conns` 形同虚设：
- Nginx 版本 ≥ 1.11.5（开源版已支持，无需商业许可）
- upstream 必须使用 least_conn 或 ip_hash 算法；round_robin、hash、random 等策略完全忽略该参数
- upstream 至少配置两台 server；单节点部署时，限流逻辑不触发
数值设定必须贴着后端真实能力来配
不是拍脑袋填个整数，而是基于后端稳定承载力打八到九折：
- Java 应用（如 Tomcat）：参考
maxThreads或线程池核心数，max_conns设为该值的 70%～90% - Go/Node.js 类轻量服务：观察其活跃 goroutine/event loop 负载峰值，预留 20% 余量
- 若后端启用了数据库连接池（如 HikariCP），需从中划出一部分连接给内部 DB 调用，不能全分给 Nginx
必须搭配 keepalive 和 HTTP/1.1 长连接
没开长连接，`max_conns` 基本无效——短连接建完就断，瞬时并发照样冲过去：
- 在 upstream 块中加：
keepalive 64;（建议值为后端连接池大小的 1/2～1/3） - 在对应 location 中启用长连接代理：
proxy_http_version 1.1;+proxy_set_header Connection ''; - 避免后端因频繁握手、TIME_WAIT 积压而提前拒绝新连接
用 queue 实现柔性排队，比硬拒绝更可控
Nginx ≥ 1.23.3 后，可在 server 行追加 queue 指令，让超额请求排队等待而非直接 502：
- 示例：
server 192.168.1.10:8080 max_conns=150 queue=10 timeout=30s; -
queue=10表示最多允许 10 个请求排队等待空闲连接 -
timeout=30s是最大等待时间，超时返回 503，用户体验优于硬丢弃
验证是否真起作用，不能只看配置
改完配置后，得靠实时指标确认它是否在工作：
- 开启
stub_status，访问/nginx_status查看各 upstream server 的 Active connections 是否稳定在max_conns × 0.8～0.9区间 - 自定义 access_log，记录
$upstream_connect_time和$upstream_addr，观察连接建立是否变慢、是否频繁切换节点 - 压测时对比前后端错误率（Connection refused / 5xx）、P95 延迟拐点，确认限流发生在预期阈值附近
