least_conn需配合健康检查、keepalive复用、max_conns限流及stream模块才能有效工作：被动/主动健康检查剔除异常节点，keepalive保障连接数统计准确，max_conns防止过载，TCP长连接须用stream模块支持。
仅靠 least_conn 本身无法识别或规避异常节点——它只看“连接数”，不判断“是否健康”。真正起作用的是与之协同的健康检查机制和连接约束策略。
必须配主动/被动健康检查
没有健康检查，least_conn 会把新请求持续发给已卡顿但 TCP 连接未断的后端，连接数越积越多，延迟飙升。关键配置有两类：
-
被动检查（推荐起步）：在
location块中启用proxy_next_upstream error timeout http_500 http_502，配合server行里的max_fails=2 fail_timeout=15s。只要连续失败 2 次，该节点就被临时剔除 15 秒 -
主动检查（更及时）：Nginx Plus 或打过 health_check 补丁的开源版支持。例如：
health_check interval=3 fails=2 passes=2 match=status_ok;，每 3 秒探测一次 HTTP 状态码和响应头
连接数统计要真实，得靠 keepalive 复用
如果后端用短连接（每个请求建一次连、马上关），Nginx 统计的“活跃连接数”瞬间归零，least_conn 就退化成伪随机调度。解决方法是：
- upstream 块内加
keepalive 32;（建议值 16–64，按 worker 数调整） - location 块中设
proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务开启连接池（如 Tomcat 的
maxKeepAliveRequests > 0，Spring Boot 的server.tomcat.max-keep-alive-requests）
用 max_conns 设置硬性容量上限
有些后端虽未宕机，但 CPU 或线程池已饱和，响应变慢却仍被 least_conn 选中。这时 max_conns 能强制跳过：
- 高性能节点：
server 10.0.1.10:8080 max_conns=2000; - 普通节点：
server 10.0.1.11:8080 max_conns=800; - 当某节点活跃 upstream 连接达到上限，Nginx 自动跳过，相当于“动态限流”
TCP 长连接场景必须走 stream 模块
数据库、WebSocket、gRPC 等不是 HTTP 协议，HTTP 上游的 least_conn 不生效。必须启用 stream 模块：
- 编译时确认含
--with-stream，运行时用nginx -V | grep with-stream验证 - stream 块内定义 upstream，同样写
least_conn;，并加zone tcp_pool 64k（多 worker 必需） - server 块监听端口后直接
proxy_pass backend_tcp;，不带协议头
