least_conn需配合健康检查、连接复用、限流缓冲才能有效应对突发流量；必须显式声明并配齐max_fails、fail_timeout、proxy_next_upstream、keepalive四项，否则无效。
least_conn 不是开个开关就能扛住突发流量的。它需要和健康检查、连接复用、限流缓冲配合，才能真正把“请求发给最闲的那台”这件事做实。
基础配置必须写全
不能只在 upstream 里写一句 least_conn; 就完事。Nginx 默认不启用这个策略，必须显式声明，且要配齐以下四项：
- 显式写 least_conn; —— 不依赖默认行为，否则实际走的是轮询
-
每个 server 行加 max_fails 和 fail_timeout，例如
server 10.0.0.1:8000 max_fails=2 fail_timeout=15s;，让 Nginx 主动感知并剔除异常节点 -
启用被动健康检查：在 location 中配置
proxy_next_upstream error timeout http_500 http_502;，配合 max_fails 才能生效 -
开启 upstream keepalive：比如
keepalive 32;，减少 TCP 建连开销；注意后端服务也得支持连接池，否则连接数统计不准
突发短连接洪峰专用组合
秒杀、抢券这类场景，大量新连接瞬间涌入，least_conn 是首选，但单靠它不够：
-
叠加 limit_req 控制速率：例如
limit_req zone=burst burst=50 nodelay;，防请求直接冲垮后端队列 - 打开 proxy_buffering 并设合理 buffer 大小，避免上游响应慢时 worker 进程被阻塞
- 缩短 keepalive_timeout 和 keepalive_requests，加快空闲连接回收，防止长连接堆积挤占资源
验证它是不是真在起作用
别只看平均响应时间或错误日志。关键要看三组指标：
- 各后端的 active connections 数是否大致均衡（可用 stub_status 或 Prometheus 抓取）
- $upstream_header_time 稳定但 $upstream_response_time 明显上升 → 问题在后端逻辑；两者同步上升 → 可能是 Nginx 层瓶颈或 least_conn 没生效
- 观察请求分布，确认新请求确实落在连接数更低的节点上，而不是因健康检查失效导致“假均衡”
运行时灵活切换算法
Nginx 不支持热改 upstream 内部算法，但可以做到秒级逻辑切换：
- 定义多个 upstream 块，如
upstream backend_least { least_conn; ... }和upstream backend_hash { ip_hash; ... } - 用 map 提取请求头或 cookie 控制目标：
map $http_x_mode $target_upstream { "least" "backend_least"; default "backend_least"; } - location 中写
proxy_pass http://$target_upstream;，改个 header 就切策略，无需 reload
