least_conn在企业级场景需确保连接数真实反映后端实时负载，须通过精准keepalive管理、主动健康检查、max_conns容量控制及多维监控验证来实现。
要让 least_conn 在企业级场景真正扛住高并发、长耗时、异构节点的真实压力，不能只看“配置有没有生效”，而得围绕它如何感知负载、如何响应异常、如何反映真实水位这三件事来评估和优化。核心不是调参数，而是确保 Nginx 看到的连接数，就是后端此刻手头真正在干的活儿。
连接数必须真实反映后端实时负载
least_conn 的调度依据只有“活跃连接数”一个数字，但它容易被虚高或失真：比如 keepalive 空闲连接长期挂着、后端不主动关闭连接、健康检查没剔掉卡死节点等。这些都会让 Nginx 误判“某台还空着”，结果把新请求继续打过去。
- upstream 块中设置 keepalive 32（不宜超过后端连接池上限），避免复用池过大拉高账面连接数
- proxy 层显式启用 HTTP/1.1 复用：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务必须支持长连接且合理释放——例如 Tomcat 配置
maxKeepAliveRequests > 0，Spring Boot 设置server.tomcat.connection-timeout=-1 - 禁用后端返回
Connection: close（常见于调试开关、WAF 干预或错误响应），否则连接池失效
健康检查必须主动、轻量、可验证
被动检查（靠超时/失败触发）无法识别“TCP 连着但业务线程卡死”的隐形黑洞。least_conn 若把请求分给这种节点，连接数可能很低，但请求全在排队等响应，实际已不可用。
- 优先启用主动健康检查：health_check interval=3 fails=2 passes=2 match=ok;（需 Nginx Plus 或开源版 1.19+ 编译 check 模块）
- 检查路径必须独立，如
/health，响应体仅含200 OK和轻量 header（如X-App-Status: ok），不走缓存、鉴权、DB 查询 - 若只能用被动模式，至少配：proxy_next_upstream error timeout http_500 http_502; + 每个 server 的 max_fails=2 fail_timeout=15s
容量控制要软硬结合，适配异构与弹性
least_conn 默认视所有节点能力均等，但现实中服务器规格不同、新实例刚上线、某节点存在隐性瓶颈（如磁盘慢、内核参数限制），都可能导致连接堆积却未被调度绕过。
- 用 max_conns 替代 weight 实现软性容量约束——高性能节点设
max_conns=3000，普通节点设max_conns=800；一旦达到即剔出调度池，不排队 - 新节点上线必加 slow_start=30s，防止冷启动瞬间涌入连接引发雪崩
- 临时维护可用 down 或 backup 标记，不影响 least_conn 动态选节点逻辑
验证必须盯住连接分布趋势，而非静态配置
上线后光确认配置无报错、日志有转发记录远远不够。关键要看连接是否真的按压力流动，有没有节点长期空闲或持续高位。
- 开启 stub_status，访问
/nginx_status查看各 server 的Active connections实时值，压测时观察是否趋于均衡 - 监控
$upstream_addr日志 + 按后端 IP 聚合的连接数变化曲线，识别长尾偏移或突增节点 - 配合后端应用指标（如线程池 busy count、GC pause 时间）交叉比对，确认 high connection 是否对应 real bottleneck
