least_conn策略通过实时感知后端活跃连接数将新请求导向最空闲健康节点，适合秒杀、ai推理等响应差异大场景；需配置健康检查、keepalive、slow_start及动态upstream路由，并强化入口缓冲与连接防护。
最少连接（least_conn）策略不是靠“平均分摊”来扛突发流量，而是靠实时感知后端真实负载，把新请求精准导向此刻最空闲的健康节点——尤其适合秒杀、抢券、AI推理等响应时间差异大的场景。
为什么它比轮询更能扛住短连接洪峰
轮询不管后端忙不忙，按顺序硬派；而 least_conn 在每个请求到来时，只看各后端当前活跃连接数。比如两台机器：A 正在处理 3 个耗时 5 秒的请求（连接未释放），B 当前连接数为 0，新请求会立刻落到 B 上，避免 A 被瞬间打满。压测显示，在 200 QPS、10% 长连接场景下，least_conn + 健康检查可将 P95 延迟稳定在 320ms 左右，轮询则可能飙升至近 500ms。
必须配齐的 4 项硬性配置
光写 least_conn; 不顶用，缺一不可：
- upstream 中每个
server必须带max_fails=2 fail_timeout=15s，让 Nginx 主动踢出异常节点 - 启用主动健康检查：
health_check interval=3 fails=2 passes=2;（开源版可用proxy_next_upstream error timeout http_500 http_502配合 passive 检查） - 后端需开启 keepalive 连接复用，Nginx upstream 内加
keepalive 32;，否则短连接频繁建断会让“连接数”失真 - 新扩容节点建议加
slow_start=30s，防止冷启动瞬间吸走过多流量
配合调度切换才真正灵活
单一算法无法覆盖所有突发类型。实际做法是定义多个 upstream：
-
upstream backend_least { least_conn; ... }（用于秒杀类短连接） -
upstream backend_hash { ip_hash; ... }（用于 WebSocket 等长连接） - 再用
map指令根据请求头或 cookie 动态路由：map $http_x_flow_type $upstream_group { "seckill" "backend_least"; "ws" "backend_hash"; default "backend_least"; }
这样无需 reload，请求即可秒级切到最适合的策略组。
别忘了入口缓冲和连接防护
least_conn 解决的是“分给谁”，但流量得先进得来、稳得住：
- 内核参数调大：
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog均设为 65535 - Nginx listen 必须显式写：
listen 80 backlog=65535;，否则默认仅 511，建连阶段就丢包 - 加连接限流防慢速攻击：
limit_conn_zone $binary_remote_addr zone=conn_perip:10m;+limit_conn conn_perip 10;
不复杂但容易忽略
