least_conn算法通过调度至活跃连接数最少的后端间接降低延迟，但需配合长连接复用、健康检查与容量限制才能真实反映压力并避免假活节点。
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 默认支持
- 对图片处理等场景，建议缩短 keepalive_timeout（如 5s），防止慢请求长期占位
排除“低连接数但高延迟”的故障节点
least_conn 只看连接数，不感知节点是否卡死、磁盘打满或内存泄漏。必须叠加健康检查才能避免调度到假活节点：
- 至少配置被动检查：proxy_next_upstream error timeout http_500 http_502; + 对应的 max_fails/fail_timeout
- 推荐主动探测：使用 nginx_upstream_check_module 或 OpenResty 的 check 指令
- 为高性能节点设更高 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 阻塞）
