least_conn算法每请求实时选择活跃连接数最少的健康后端，仅统计Nginx与后端间未关闭的TCP连接（含keepalive空闲连接），不依赖响应时间、权重或历史数据，需配合max_fails/fail_timeout健康检查及upstream keepalive配置才能准确反映真实负载。
Nginx 最少连接（least_conn）调度不是靠预测或历史数据，而是每收到一个新请求时，立即检查所有健康后端的当前活跃连接数，把请求发给数值最小的那个节点——它不看响应时间、不比权重比例、也不依赖全局状态同步，只认“此刻谁最空闲”。
least_conn 怎么感知真实压力
它统计的是 Nginx 与后端之间已建立但尚未关闭的 TCP 连接数，包括：
- 正在处理 HTTP 请求的长连接
- Keepalive 空闲连接（只要没超时、没被主动关闭）
- WebSocket、gRPC、数据库代理等持续占用的连接
这个数字在每个 worker 进程内实时更新，若启用了 zone 指令（如 upstream backend { zone backend_zone 64k; }），还能跨 worker 共享统计，避免多进程下连接数误判。
为什么光写 least_conn 不够
连接数只是表象，背后必须有配套机制让这个数字反映真实负载：
- 没有
max_fails和fail_timeout，宕机或卡死的节点仍被计入“可用”，least_conn 会不断往它身上派新连接 - 没配
keepalive N，短连接频繁新建/断开，连接数跳变剧烈，“最少”变成伪随机分配 - 后端服务自身未开启连接复用（如 Tomcat 的
maxKeepAliveRequests关闭），Nginx 统计的连接数无法稳定反映实际承载压力
验证它是否真在起作用
不能只看单次请求日志，要观察趋势：
- 启用
stub_status，访问/nginx_status查看各 upstream 的Active connections实时值 - 用
wrk -t4 -c100 -d30s持续压测，对比各后端 access log 中的请求数分布 - 故意让一台后端响应变慢（如加 sleep(2)），观察其连接数是否明显高于其他节点，以及是否因连续失败被临时剔除
和轮询相比，适合什么场景
least_conn 的优势不是“更平均”，而是“更贴合动态负载”：
- 后端有部分接口耗时波动大（比如含慢 SQL 或第三方调用）
- 使用 HTTP/1.1 持久连接或长连接协议（如 WebSocket）
- 服务器硬件配置不一致（如混合部署旧机型与新机型）
- 出现过轮询下某节点连接堆积、超时率突增的情况
