least_conn能实时将新请求导向连接数最少的健康后端，适合秒杀等短连接洪峰场景；它比轮询更稳，因会跳过已堆积连接的节点，响应毫秒级且无需人工干预；需配置server的max_fails与fail_timeout、proxy_next_upstream、upstream keepalive及后端连接池；还需搭配limit_req限流、proxy_buffering缓冲和keepalive优化；验证时应监控各后端active connections是否不均衡、upstream_header_time与response_time变化趋势及实际请求分布。
least_conn 能在突发流量下自动把新请求导向连接数最少的健康后端，不靠预设规则，只看“此刻谁最空闲”。它不是预测性调度，而是每请求一次就实时比对、即时决策，天然适合秒杀、抢券这类短连接洪峰场景。
为什么突发时 least_conn 比轮询更稳
轮询不管后端是否正处理耗时任务，而 least_conn 会跳过已堆积连接的节点。例如某台后端因 GC 卡顿，活跃连接快速升到 180，其余两台仍为 5 和 2——新请求就会全部落在连接数为 2 的那台，避免延迟雪崩。这种响应是毫秒级的，无需人工干预或配置变更。
必须配齐的四个基础项
单独写 least_conn; 不足以生效：
- 每个 server 行要带 max_fails=2 fail_timeout=15s，让异常节点能被及时剔除
- 启用被动健康检查：proxy_next_upstream error timeout http_500 http_502，配合 max_fails 才起作用
- upstream 块内加 keepalive 32，确保连接复用，否则连接数统计失真
- 后端服务本身得支持连接池，否则 Nginx 看到的“活跃连接”不能真实反映负载
搭配限流与缓冲才真正抗压
least_conn 只解决“往哪发”，不控制“发多少”和“怎么收”：
- 用 limit_req zone=burst burst=50 nodelay 控制请求速率，防洪峰直接冲垮后端队列
- 开启 proxy_buffering on 并设合理 buffer 大小，避免上游响应慢时 worker 被阻塞
- 缩短 keepalive_timeout 和 keepalive_requests，加快长连接回收，让连接数统计更灵敏
验证它是不是真在工作
别只盯平均延迟。要看三组指标：
- 各后端的 active connections 是否明显不均衡（可用 stub_status 或 Prometheus 抓取）
- $upstream_header_time 稳但 $upstream_response_time 升高，说明问题在后端逻辑；两者同步升高，可能是 least_conn 没起作用或 Nginx 层瓶颈
- 观察请求分布，确认流量确实落在连接数低的节点上，而非因健康检查失效导致“假均衡”
