least_conn 是专为高并发动态接口设计的负载均衡策略，需配合健康检查、keepalive调优和max_conns容量控制才能真正生效。
least_conn 不是“选连接少的机器”这么简单，它在高并发动态网关中真正起效，靠的是让新请求绕开正在处理慢任务的节点——尤其适合登录、下单、搜索这类响应时间从20ms到8秒不等的动态接口。
必须放在 upstream 块第一行，且不能混用其他 hash 类策略
least_conn 是 upstream 级指令，只在 upstream 块内生效：
- 正确写法：upstream api_gateway { least_conn; server 10.0.2.10:3000; server 10.0.2.11:3000; }
- 错误写法：把它写在 http 块顶层，或和 ip_hash、hash $cookie_sessionid 放在同一 upstream 里，Nginx 会直接报错 “directive is not allowed here”
- 有状态接口（如支付回调）需会话保持，建议单独建一个 ip_hash 或 cookie 哈希 upstream，不要强行塞进 least_conn 组
健康检查必须主动 + 被动双管齐下
least_conn 只看连接数，不判断后端是否真能干活。一台机器卡在 GC 或数据库锁表，连接数可能很低，但新请求一打就超时。
- 被动检查必配：proxy_next_upstream error timeout http_500 http_502;，再配合每个 server 的 max_fails=2 fail_timeout=15s
- 主动检查更可靠（Nginx Plus 或带 health_check 模块的开源版）：每 3 秒 GET /health，要求返回 200 且响应头含 X-App-Status: ok
- 健康检查路径要独立、轻量，绝不复用业务接口，避免检查本身加重后端压力
keepalive 和后端连接池必须协同调优
如果每次请求都新建 TCP 连接，活跃连接数瞬间涨落，least_conn 就变成伪随机分配。
- upstream 内加：keepalive 32;（建议值 16–64，按后端平均并发反推）
- 转发时显式启用 HTTP/1.1 复用：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务必须开启连接池：Tomcat 设 maxKeepAliveRequests > 0，Go Gin 可配 http.Server.IdleTimeout
- 检查后端响应是否含 Connection: close——常见于 WAF 干预或调试开关打开，这会让 keepalive 失效
用 max_conns 替代 weight 实现真实容量感知
least_conn 原生不支持 weight，但 max_conns 能让算法在“连接最少”的前提下，自然倾向能力更强的节点。
- 高性能节点（32C64G）设 server 10.0.2.10:3000 max_conns=3000;
- 普通节点（16C32G）设 server 10.0.2.11:3000 max_conns=1200;
- 一旦某节点活跃连接 ≥ max_conns，Nginx 自动跳过它参与比较，不排队不等待
- 新实例上线加 slow_start=30s，权重从 0 线性升至满额，防冷启动雪崩
