直接在upstream块首行写least_conn;即可启用最小连接数策略，但企业级落地需确保连接数真实（keepalive+HTTP/1.1+后端协同）、节点可用（被动+主动健康检查）、调度可控（max_conns限容、禁用互斥策略）、行为可验（stub_status+监控）。
直接在 upstream 块首行写 least_conn; 就启用了最小连接数策略，但它只是调度逻辑的起点——企业级落地必须围绕“连接数真实、节点可用、调度可控、行为可验”四个核心构建运维规范。
配置结构必须合规：位置、互斥与基础语法
least_conn 是 upstream 级指令，仅允许出现在 upstream 块第一行：
- ✅ 正确：
upstream api_cluster { least_conn; server 10.20.30.1:8000; ... } - ❌ 错误：放在 http/server/location 块中，或写在 server 行之后，Nginx 启动即报
directive is not allowed here - 禁止混用
ip_hash、hash、least_time等互斥策略；同一 upstream 中只能启用一种主调度算法 -
weight不影响最小连接判断，但连接数相同时会触发加权轮询 fallback，可用于新老机型混部场景
连接管理必须标准化：keepalive + HTTP/1.1 + 后端协同
没有连接复用，least_conn 就退化为近似随机分配。企业环境需统一连接生命周期策略：
- upstream 中强制启用连接池：
keepalive 32;（推荐值 16–64，不超过后端连接池上限） - proxy_pass 所在 location 必须显式声明：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端服务需开启长连接支持：如 Spring Boot 设置
server.tomcat.connection-timeout=-1，Uvicorn 启动参数加--keep-alive 5，Tomcat 配置maxKeepAliveRequests="1000" - 避免 keepalive_timeout 过长（如 >120s），防止空闲连接虚高干扰调度灵敏度
健康保障必须双轨制：被动容错 + 主动探测
least_conn 不感知进程卡死、线程阻塞、GC 暂停等“假存活”状态，企业级必须叠加健康检查：
- 每个 server 行标配被动检查：
max_fails=2 fail_timeout=15s - 全局启用错误重试：
proxy_next_upstream error timeout http_500 http_502 http_503; - 生产环境建议部署主动健康检查：使用 Nginx Plus 的
health_check，或开源版编译ngx_http_upstream_check_module，探测路径独立（如/health?ready=1），响应轻量、不走业务链路 - 异常节点恢复后应自动回归 least_conn 调度池，不依赖人工干预
容量控制与可观测性必须常态化
企业系统需防止单点过载和调度失焦，必须固化以下运维动作：
- 为每台后端设置硬性并发上限：
server 10.20.30.1:8000 max_conns=800;（高性能节点可设 1600–2000，普通节点 600–800） - 上线前必开
stub_status：location /nginx_status { stub_status; }，用于实时查看各 server 的Active connections分布 - 日志中固定记录
$upstream_addr和$upstream_connect_time，结合 Prometheus + nginx-module-vts 或自定义 exporter 实现连接数趋势监控 - 压测阶段比对 least_conn 与 round-robin 在 P95 连接分布、超时率、后端 ESTABLISHED 连接数（
ss -n state established '( dport = :8000 )' | wc -l）三维度差异
