least_conn策略需配合主动健康检查、合理keepalive设置、权重与slow_start配置及实时连接监控才能真正生效；否则仅启用该策略无法提升性能。
最少连接策略（least_conn）在 Web 集群中不是“挑个空闲机器”，而是让 Nginx 在每次请求到达时，从当前健康节点中选出活跃连接数最少的那台后端——它真正起效的前提，是 Nginx 能准确感知“谁真忙、谁真闲”。单纯加一行 least_conn 很难带来性能提升，关键在于调度逻辑与后端真实负载状态的对齐。
健康检查必须主动，不能只靠被动失败
默认情况下，Nginx 不会主动探测后端是否存活，仅靠连接失败或超时触发重试。这意味着：某台后端进程卡死但 TCP 连接未断，它仍持续计入“活跃连接数”，新请求还会被分过去，形成隐形黑洞。
- 推荐配置主动健康检查（需 Nginx Plus 或开源版编译
ngx_http_upstream_check_module）：health_check interval=3 fails=2 passes=2 match=ok; - 若用开源版，至少启用被动检查：
proxy_next_upstream error timeout http_500 http_502;并配合每个server的max_fails=2 fail_timeout=15s - 健康检查路径建议独立（如
/health），响应体轻量、不走业务逻辑，避免干扰真实负载统计
keepalive 设置直接影响连接数真实性
upstream 的 keepalive N 指令会让 Nginx 复用与后端的空闲连接，这些连接仍算作“活跃连接”。如果复用池过大或后端不释放连接，就会虚高连接计数，导致 least_conn 失去灵敏度。
- 建议 upstream 中设置
keepalive 32;（不宜超过后端连接池上限） - 后端服务必须开启长连接支持（如 Tomcat 的
maxKeepAliveRequests > 0，Spring Boot 的server.tomcat.connection-timeout=-1） - 在 proxy 层显式控制连接复用行为：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
权重与 slow_start 是应对异构与扩容的关键
纯 least_conn 默认把所有节点视为能力均等。但在实际集群中，服务器规格不同、新实例刚上线、或某节点存在隐性瓶颈（如磁盘 I/O 慢），都可能造成连接堆积却未被剔除。
- 用
weight反映硬件差异：CPU 强 2 倍的机器设weight=2，Nginx 会在连接数相近时倾向多分请求 - 新节点上线务必配
slow_start=30s，避免冷启动瞬间涌入大量请求引发雪崩 - 可结合
down或backup标记临时维护节点，不影响 least_conn 动态选择逻辑
验证不能只看日志，要盯住实时连接分布
上线后光看 $upstream_addr 日志只能知道“落到哪台”，无法判断是否真均衡。需组合监控指标：
- 启用
stub_status或 Prometheus exporter，实时查看各 upstream server 的active connections - 对比
$upstream_connect_time和$upstream_header_time：前者突增说明网络或连接池问题；后者突增才指向后端处理慢 - 压测时观察 P95 延迟和连接数标准差——least_conn 有效时，各节点连接数波动应明显小于轮询（例如标准差从 8.2 降至 2.1）
