least_conn算法需配合健康检查、连接复用和容量控制才有效；必须置于upstream块首行，各server须配max_fails、fail_timeout、max_conns等参数，并启用keepalive及限流防护。
least_conn 算法本身不抗冲击，真正起效靠的是完整配置组合。它把请求发给当前活跃连接最少的后端，但若健康检查、连接复用或容量控制没配好，面对突发流量时就容易失效甚至反向加剧不均。
必须写对的位置和语法
least_conn 只能出现在 upstream 块的第一行，紧接在 upstream 名称之后：
- 正确：upstream api_cluster { least_conn; server 10.0.1.10:8000; ... }
- 错误：放在 http/server/location 块里 → 启动报错 “directive is not allowed here”
- 错误：写在 server 行后面 → 被忽略或校验失败
- 错误：和 ip_hash、hash、least_time 共存 → 配置无法通过
每个 server 必须配的关键属性
光写 least_conn; 不够。每个后端节点需明确表达其真实承载能力与异常响应边界：
- max_fails=2 fail_timeout=15s：启用被动健康检查，异常节点快速下线，避免调度到“假空闲”机器
- max_conns=2000（按实际调整）：硬性限制最大并发连接数，让算法在容量范围内比较，防止高负载节点持续收请求
- slow_start=30s（新节点建议加）：冷启动阶段流量线性接入，防雪崩
示例：server 10.0.1.10:8000 max_fails=2 fail_timeout=15s max_conns=2000 slow_start=30s;
连接复用必须开启
least_conn 统计的是活跃 TCP 连接数。如果后端总是短连接，连接数瞬间归零，算法就退化为随机分配：
- 在 upstream 块中加：keepalive 32;（每 worker 最多缓存 32 条空闲连接）
- 在 location 中加：proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 后端服务需支持长连接：如 FastAPI/Uvicorn 开启 keep-alive，Tomcat 设置 maxKeepAliveRequests > 0
- 检查后端响应头是否含 Connection: close——常见于错误返回或 WAF 干预，会强制断连
搭配限流与健康探测才稳
least_conn 解决“往哪发”，但不控制“发多少”和“怎么收”。突发流量下还需叠加防护：
- limit_req zone=burst burst=50 nodelay：控制请求速率，防洪峰直接冲垮后端队列
- proxy_next_upstream error timeout http_500 http_502：配合 max_fails 生效，提升被动检查灵敏度
- 有条件加主动 health_check（商业版或 patch 版），interval=3s fails=2 passes=2，用 match 校验状态码和关键响应头
- 健康检查路径要独立、轻量、绕过鉴权和缓存，避免检查本身加重后端压力
验证是否真生效
别只看配置是否通过。重点观察行为是否符合预期：
- 开启 stub_status，访问 /nginx_status 查看各后端 Active connections 是否随压测趋于均衡
- 用 curl -I 或 access log 确认请求确实落在连接数更少的节点上
- 监控 $upstream_header_time 和 $upstream_response_time 分离趋势：前者稳、后者升 → 后端逻辑瓶颈；两者同步升 → least_conn 没起作用或 Nginx 层卡住
- 若某节点连接数低但延迟飙升，说明健康检查没跟上，需加强主动探测
