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 表示不限制）

数值怎么设才不拍脑袋

不能凭感觉定，要贴着后端真实瓶颈来配：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 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 内存中，不增加后端压力

不复杂但容易忽略。