max_conns 是软性约束，需结合版本≥1.11.5、least_conn/ip_hash算法、多节点、HTTP/1.1长连接、压测定值、keepalive与queue机制及监控闭环才有效。
max_conns 本身不是“严格限制开关”，它只在特定条件下构成一层连接数层面的软性约束。想让它在突发洪峰下真正守住后端路径不被压垮，必须把它放进一个可感知、可排队、可回退、可验证的闭环里，而不是单独设个数字就指望生效。
确认基础前提是否全部满足
这是调优的第一步，缺一不可：
- Nginx 版本 ≥ 1.11.5（推荐 ≥ 1.23.3，以便启用 queue）
- upstream 使用 least_conn 或 ip_hash 算法（round_robin 完全不读取 max_conns）
- upstream 至少配置两台 server（单节点时 max_conns 不触发限流逻辑）
- 后端服务支持 HTTP/1.1 长连接，且未主动关闭 keep-alive
数值设定要匹配后端真实吞吐能力
不能拍脑袋填，得靠压测数据驱动：
- 先对单台后端做压测，找到响应时间明显恶化（如 P95 > 500ms）或错误率陡升（5xx > 1%）的并发点
- 把这个临界并发值乘以 0.8～0.9，作为 max_conns 初始值（例如后端稳定上限为 200，则设 max_conns=160～180）
- 避免 max_conns ≥ 后端连接池上限（如 Tomcat 的 maxConnections），否则仍会触发 Connection refused
必须配套长连接与排队机制
没有 keepalive，max_conns 基本失效；没有 queue，洪峰来时直接丢请求，保护效果打折：
- 在 upstream 块中启用连接复用：keepalive 64;（建议设为 max_conns 的 30%～50%，避免空闲连接长期占位）
- 在 proxy location 中强制长连接：proxy_http_version 1.1; + proxy_set_header Connection '';
- 升级到 Nginx ≥ 1.23.3 后，启用柔性排队：server 10.0.1.10:8080 max_conns=160 queue=8 timeout=20s;
配合监控与健康检查形成闭环
光配不看等于没配。关键指标要实时可观测：
- 通过 nginx_stub_status 或 vts 模块 查看各 server 的 active connections，确认是否稳定在 max_conns × 0.8～0.9 区间
- 监听 error log 中的 “upstream queue is full” 或 “no live upstreams”，判断是否真被触发
- 配置主动健康检查：max_fails=2 fail_timeout=15s，快速摘除已响应迟缓或超时的节点
- 将 upstream_addr 和 upstream_status 写入自定义日志，便于定位是连接拒绝还是后端主动 reset
