least_conn是Nginx stream模块中基于实时活跃连接数最少的后端节点转发新连接的负载均衡策略，适用于TCP/UDP长连接场景，需在upstream块首行配置、配合健康检查与stub_status验证。
在 Nginx 的 stream 模块中，least_conn 是一种上游负载均衡策略，它会将新连接转发给当前活跃连接数最少的后端节点，适合长连接场景（如 TCP/UDP 代理、数据库代理等）。要通过 stream_upstream 配置实现该策略，关键在于正确使用 least_conn 指令，并确保上游服务器状态可被准确统计。
配置 least_conn 负载均衡的 upstream 块
在 stream 上下文中定义 upstream 时，直接在 upstream 块内添加 least_conn 指令即可启用最少连接算法：
upstream backend {
least_conn;
server 192.168.1.10:3306;
server 192.168.1.11:3306;
server 192.168.1.12:3306;
}
注意：least_conn 必须是 upstream 块中的**首条指令**（在所有 server 行之前），否则 Nginx 会报错或降级为轮询（round-robin）。
确保连接计数准确生效
Nginx stream 模块依赖连接的“建立”和“关闭”事件来更新每个 server 的活跃连接数。以下情况会影响 least_conn 效果：
- 后端服务未正常关闭连接（如 MySQL 空闲连接未断开），会导致连接数长期虚高
- 启用了
proxy_timeout或tcp_nodelay等参数但未配合连接回收机制，可能延迟连接释放 - 使用了
keepalive指令但未设置合理的keepalive_timeout，使连接长时间挂起
建议搭配以下配置提升准确性：
upstream backend {
least_conn;
server 192.168.1.10:3306 max_fails=3 fail_timeout=30s;
server 192.168.1.11:3306 max_fails=3 fail_timeout=30s;
server 192.168.1.12:3306 max_fails=3 fail_timeout=30s;
}
server {
listen 3307;
proxy_pass backend;
proxy_timeout 30s;
proxy_responses 1;
}
验证 least_conn 是否生效
可通过 Nginx 内置状态接口（需编译时启用 --with-stream_upstream_module 和 --with-stream_stub_status_module）查看各 server 的实时连接数：
# 在 stream 块中添加
upstream_status {
stub_status;
}
server {
listen 127.0.0.1:8081;
upstream_status;
}
访问 http://127.0.0.1:8081 可看到类似输出：
Upstream: backend
Server: 192.168.1.10:3306 Active: 12
Server: 192.168.1.11:3306 Active: 5
Server: 192.168.1.12:3306 Active: 8
此时新连接应优先落到 Active 数最小的节点（如 192.168.1.11）。
注意事项与常见误区
不支持权重（weight）：least_conn 不兼容 weight 参数，加了会被忽略；如需加权最少连接，需借助第三方模块（如 nginx-plus 或 openresty 的 lua-resty-upstream-healthcheck）。
仅统计当前 worker 进程内的连接：Nginx 多 worker 下，least_conn 是 per-worker 统计，非全局一致。高并发下可能出现轻微偏差，但对大多数场景影响可控。
健康检查需额外配置：least_conn 本身不触发健康检查，建议配合 health_check 指令（Nginx Plus）或外部探活工具，避免故障节点持续接收连接。
