least_conn算法需配合健康检查、keepalive、max_conns及stream模块（tcp场景）才能真实缩短响应时间；仅启用算法本身无法规避慢节点或感知真实负载。
要真正用最小连接（least_conn）算法缩短全局响应时间，关键不是“开了这个算法”就完事，而是让 Nginx 能准确感知每台后端的真实负载压力，并快速规避异常节点。否则连接数统计失真、慢节点持续吸请求，反而拉高延迟。
必须显式启用 least_conn 并配齐健康控制
算法本身只看活跃连接数，但若节点已卡顿却未被隔离，least_conn 会继续往它身上塞新连接——结果就是堆积+超时+雪崩。所以这四点缺一不可：
- upstream 块首行明确写 least_conn;（不能省略，也不能放在 server 行后面）
- 每个 server 必须带 max_fails=2 fail_timeout=15s 这类参数，让失败能触发临时剔除
- 配合 proxy_next_upstream error timeout http_500; 开启被动健康检查，使 max_fails 生效
- 后端服务需支持长连接，且 Nginx upstream 内启用 keepalive 32;，避免短连接干扰连接数统计
适配性能差异：用 max_conns 替代 weight
least_conn 会忽略 weight 参数，所以不能靠 weight 来表达机器强弱。更合理的方式是用 max_conns 设置硬性上限：
- 高性能节点设 server 10.0.1.10:8080 max_conns=2000;
- 普通节点设 server 10.0.1.11:8080 max_conns=800;
- 当某节点活跃连接达到 max_conns，least_conn 自动跳过它，相当于“动态容量感知”
TCP 长连接场景要额外启用 stream 模块
如果是数据库、游戏网关、WebSocket 等 TCP 层长连接服务，HTTP 的 upstream 不适用。必须启用 stream { upstream } 模块：
- 编译时确认含 --with-stream，运行中用 nginx -V | grep with-stream 验证
- stream 块内定义 upstream，同样用 least_conn; + weight + zone tcp_pool 64k（多 worker 必须加 zone）
- server 块中 listen 明确端口，proxy_pass 直接写 upstream 名，不带协议头
验证是否真起作用：盯住连接数与延迟波动
配置生效后，别只看日志有没有报错。重点观察两个指标：
- 通过 stub_status 或 Prometheus exporter 查各 backend 的 Active connections，理想状态是数值紧贴、无长期偏离（比如一台稳定在 40+，其他都在 15 左右）
- 压测时对比 P95 延迟：有健康检查+keepalive 的 least_conn，通常比轮询低 15%–30%，尤其在出现单点抖动时优势明显
