least_conn通过分配请求至连接数最少的后端间接降低延迟，适用于响应时间差异大的场景；必须配置在upstream块内，需配合长连接、健康检查及容量限制使用，并结合监控验证效果。
least_conn 算法本身不直接优化延迟，但它通过把新请求导向当前活跃连接数最少的后端，间接避开正在处理长耗时任务的节点，从而降低整体响应延迟——尤其适合接口响应时间差异大、存在计算密集型请求（如AI推理、报表导出、图片解码）的场景。
核心配置必须写在 upstream 块内
least_conn 是 upstream 指令级参数，不能放在 http 块顶层或 server 块中。错误写法会报 “directive is not allowed here”。正确结构如下：
- 以 upstream 名称 { least_conn; 开头，且必须是该块第一条有效指令之一
- 每个 server 行后可附加健康检查参数（如 max_fails=2 fail_timeout=15s），但不能跟 weight（权重会被静默忽略）
- 不可与 ip_hash、hash、least_time 等策略混用
让连接数真实反映实时压力
若后端使用短连接，每次请求新建+关闭，Nginx 统计的 active 连接数就失去意义。需确保连接复用稳定：
- 在 upstream 中启用连接池：keepalive 32;（每 worker 进程最多缓存 32 个空闲长连接）
- 在 location 中启用 HTTP/1.1 长连接：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务也要支持 keep-alive：例如 Tomcat 设置 keepAliveTimeout > 0，Node.js 默认支持
排除“低连接数但高延迟”的故障节点
least_conn 只看连接数，不感知节点是否卡死或磁盘打满。必须叠加健康检查才能避免调度到假活节点：
- 使用开源模块 nginx_upstream_check_module 或 OpenResty 的 check 指令做主动探测
- 至少配置被动检查：proxy_next_upstream error timeout http_500 http_502; + 对应的 max_fails/fail_timeout
- 为高性能节点设更高 max_conns（如 2000），普通节点设较低值（如 800），实现带容量边界的 least_conn
验证是否真正降低延迟
不能只看日志请求数分布，要结合连接状态与响应时间交叉分析：
- 开启 stub_status，访问 /nginx_status 查看各 server 的 active 连接数是否随压测趋于均衡
- 采集 $upstream_connect_time 和 $upstream_header_time，识别连接建立快但业务处理慢的异常节点
- 绘制 active connections vs response time 散点图，定位“连接数低但延迟高”的离群点（常见于内存泄漏、本地缓存失效或磁盘 I/O 阻塞）
