least_conn算法每次将新请求发给当前活跃连接数最少的健康后端，不依赖响应时间或资源指标，需配合keepalive、健康检查与max_conns配置才能准确反映真实负载。
least_conn 本身不保证“始终”流向负载最低的节点，它只确保每次新请求发给当前活跃连接数最少的后端——这个判断是瞬时、局部、基于连接数的，不是全局负载评估。要让效果更贴近“负载最低”，需围绕连接数这个唯一依据做精准配置和协同优化。
正确启用 least_conn 的基础写法
必须在 upstream 块内首行声明，不能放在 http 块顶层或其他位置：
- 配置示例：
upstream backend { least_conn; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; } - least_conn 不接受任何参数，也不支持 weight；写上 weight=2 会被静默忽略
- 同一 upstream 中不可混用 ip_hash、hash 或 least_time 等互斥策略
让连接数真实反映后端压力
连接数统计失真，least_conn 就失去意义。关键在于避免短连接干扰，强制复用长连接：
- 在 upstream 中启用 keepalive，并设合理值（如 32），每个 worker 进程可缓存空闲连接
- location 中必须显式开启 HTTP/1.1 并清空 Connection 头：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
- 后端服务需支持长连接（如 Tomcat 启用 keepAliveTimeout，Node.js 默认支持）
- 对图片处理等场景，反而建议缩短 keepalive_timeout（如 5s），防止慢请求长期占位
排除故障节点，避免“最低连接数但已不可用”
least_conn 不感知健康状态。若某台机器网络不通或进程僵死，只要 TCP 连接未断，它仍可能被选中：
- 搭配主动健康检查：使用 nginx_upstream_check_module（开源版）或 OpenResty 原生 check 指令
- 示例：
upstream backend { least_conn; check interval=3 rise=2 fall=3 timeout=1 type=http; server 192.168.1.10:8080; server 192.168.1.11:8080; } - 设置 max_conns（如 200）为单节点加硬上限，防止单个慢请求拖垮整条连接队列
验证是否真正生效
不能只看日志请求数，要观察实时连接分布：
- 开启 stub_status 模块，在 server 块中添加 location /nginx_status，访问后查看各 server 的 active 连接数
- 压测时用 curl -I 多次请求，比对后端 access log 中各节点实际接收连接数是否随时间趋于均衡
- 监控 active connections + response time 散点图，识别“连接数低但延迟高”的异常节点（可能是磁盘满、内存泄漏）
