least_conn在大促中易因连接统计失真、冷启动、慢请求堆积等导致流量打向实际卡死的后端；需通过keepalive复用、max_conns限流、slow_start防冷启、主动健康检查、按业务分离upstream及实时监控三类指标，构建真实负载感知的调度闭环。
least_conn 在大促场景下容易因连接统计失真、节点冷启动、慢请求堆积或健康反馈滞后，导致流量仍打向“账面空闲但实际卡死”的后端。要让它在高并发、高波动的流量下真正扛住压力，关键不是加一行指令，而是构建一套能实时反映真实负载的调度闭环。
让连接数真实反映大促时的实际压力
大促期间短连接激增、后端响应延迟上浮、连接复用率下降——这些都会让 least_conn 的“活跃连接数”严重失真：
- 在 upstream 块中显式启用 keepalive 32（不宜超过后端连接池上限），避免每个请求都新建 TCP 连接，否则活跃连接数始终趋近于 0，least_conn 退化为随机分配
- 在 proxy_pass 所在 location 中强制 HTTP/1.1 复用：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务必须支持 keep-alive：Spring Boot 需设
server.tomcat.connection-timeout=5s，FastAPI/Uvicorn 加--keep-alive 5，避免空闲连接长期滞留干扰统计 - 若后端返回
Connection: close（常见于 WAF 拦截、调试开关开启或错误响应），Nginx 无法复用连接，需排查响应头源头
防冷启动、防长尾、防假空闲
大促扩容新节点或某台机器突发 GC 卡顿，least_conn 无法主动识别，必须靠配置兜底：
- 所有 server 行必须配 max_conns=800（高性能节点可设 1500–2000，普通节点建议 600–800），一旦达到即剔出调度池，防止单点被长尾请求锁死
- 新上线节点加 slow_start=30s，让连接权重从 0 线性升至满额，避免模型未加载完、缓存未预热就承接全量流量
- 设置 proxy_read_timeout 120（略高于后端 P99 耗时），配合 proxy_next_upstream error timeout http_500 http_502，让卡住的请求及时失败并重试其他节点，释放连接槽位
- keepalive_timeout 不宜过长（建议 5–10s），避免空闲连接长期占位，拉高“账面连接数”造成误判
健康检查必须主动且轻量
被动检查（靠超时/失败触发）在大促中太迟钝——节点可能已线程阻塞、显存耗尽，但 TCP 连接仍通，least_conn 会持续分发请求：
- 优先启用主动健康检查：health_check interval=3 fails=2 passes=2 match=ok;（需 Nginx Plus 或编译 ngx_http_upstream_check_module）
- 若仅用开源版，至少强化被动机制：每个 server 配 max_fails=2 fail_timeout=10s，并确保 proxy_next_upstream 包含
error timeout http_500 http_502 - 健康检查路径必须独立（如
/health），响应体小于 1KB，绕过鉴权、缓存与业务逻辑，避免检查本身加重后端负担
按业务分离流量路径，避免相互污染
大促期间订单、支付、库存接口响应时间差异极大，混用同一 upstream 会导致 least_conn 失效：
- 为长耗时任务（如核销、对账、报表导出）单独定义 upstream，启用 least_conn + max_conns=50–100（严格限制单节点并发）
- 短平快接口（如商品查询、优惠券校验）走另一组 upstream，可用轮询或 hash $arg_sku_id 实现局部缓存亲和
- AI 推理等高算力接口建议再隔离，搭配 max_conns=20–40 和更短的 proxy_read_timeout 30，避免一次慢推理拖垮整条链路
上线后盯紧三类指标，不只看配置是否生效
大促前压测和上线后监控，重点验证 least_conn 是否真的在动态均衡：
- 开启 stub_status：在 server 块中加
location /nginx_status { stub_status; }，压测时观察各 backend 的Active connections是否趋于均衡，有无单点持续偏高 - 交叉比对后端真实连接数：
ss -tan state established '( sport = :8080 )' | wc -l，确认与 Nginx 统计一致，排除后端 linger 设置过长导致连接滞留 - 结合日志分析
$upstream_addr分布，用脚本统计 1 分钟粒度的节点命中率，波动超过 ±15% 就需回查 max_conns 或健康检查是否异常
