max_conns=N生效需四个前提：Nginx≥1.11.5、upstream用least_conn或ip_hash、至少两台后端、每server明确配置；须结合后端瓶颈设值，搭配keepalive长连接，并可选queue柔性排队。
直接在 upstream 块的每个 server 行里写上 max_conns=N，只是第一步；它真正起作用，必须和负载策略、长连接、后端承载力对齐，否则形同虚设。
确保 max_conns 能生效的硬性条件
这个参数不是“写了就管用”，四个前提缺一不可：
- Nginx 版本 ≥ 1.11.5（开源版已支持，无需 Plus 许可）
-
upstream必须使用least_conn或ip_hash算法；round_robin（默认）完全忽略该参数 -
upstream至少配置两台后端 server；单节点部署时，max_conns 不触发限流 - 每个
server行明确写出max_conns=N（默认值 0 表示不限制）
数值怎么设才不拍脑袋
不能凭感觉定，要贴着后端真实瓶颈来配：
- Java 应用（如 Tomcat）：参考
maxThreads，设为它的 70%～90%。例如线程池上限是 200，max_conns可设 140～180 - Go/Node.js 类轻量服务：观察其稳定运行时的活跃连接或协程峰值，预留 20% 余量
- 若后端用了数据库连接池（如 HikariCP），需额外留出 20% 连接给内部 DB 调用，别把所有额度都分给 Nginx
- 压测找拐点更可靠：比如后端并发到 300 时 P95 延迟陡升或错误率明显上升，就把
max_conns初设为 240～270
必须搭配 keepalive 长连接才稳定
没开长连接，max_conns 基本失效——短连接建完就断，连接数瞬时冲高又回落，Nginx 很难持续触达上限：
- 在
upstream块中加：keepalive 64;（建议值为后端连接池大小的 1/2～1/3） - 在对应
location中启用 HTTP/1.1 长连接代理：proxy_http_version 1.1;和proxy_set_header Connection ''; -
keepalive数值不宜大于max_conns，否则空闲连接堆积会绕过限制
用 queue 实现柔性排队，避免硬拒绝
Nginx ≥ 1.23.3 时，可让超限请求排队等待，而不是直接返回 502：
- 写法示例：
server 192.168.1.10:8080 max_conns=180 queue=10 timeout=30s; -
queue=10表示最多允许 10 个请求排队等待空闲连接 -
timeout=30s是最大等待时间，超时返回 503，比 502 更明确表达“暂时不可用” - 注意：
queue仅在least_conn下有效，且排队发生在 Nginx 内存中，不增加后端压力
不复杂但容易忽略。
