least_conn需配合主动健康检查才能保障高可用；推荐配置check interval=3 rise=2 fall=3 timeout=1 type=http uri=/health，轻量隔离的健康接口、keepalive与HTTP/1.1复用、max_conns限流及slow_start冷启动保护缺一不可。
least_conn 本身不保证高可用，它只负责“挑当前连接最少的后端”，但如果后端已卡死、假活或响应极慢，而 Nginx 还把它算作“健康且连接少”，那新请求就会掉进黑洞。真正起作用的，是 least_conn 和主动健康检查的组合——前者管“谁轻”，后者管“谁真在干活”。
必须用主动健康检查替代被动失败触发
默认的 passive 检查（靠请求超时或 502 才标记失败）太迟钝：一台后端进程僵死但 TCP 连接没断，least_conn 仍会把它当“空闲节点”持续分发请求。
- 推荐配置（需编译 nginx-upstream-check-module）：
check interval=3 rise=2 fall=3 timeout=1 type=http uri=/health;
每 3 秒发一次 HEAD 请求到 /health，连续 3 次失败即标记为 down，并立即关闭所有指向它的空闲连接 - 若无法加模块，至少强化被动策略：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
并为每个 server 显式设max_fails=2 fail_timeout=15s，避免单次抖动误判
健康接口要轻量、隔离、可收敛
/health 不能走业务链路，否则检查本身会拖慢后端，甚至引发雪崩。
- 只校验进程存活 + 端口监听状态，禁用数据库查询、远程调用等依赖
- 路径独立（如 /healthz），不与业务路由共用中间件或日志埋点
- 返回体保持空或简单 JSON（
{"status":"ok"}），避免序列化开销
least_conn 的准确性依赖连接真实态
它统计的是“已建立且未关闭”的连接数，不是理论值。以下配置直接影响它的判断质量：
-
upstream中启用keepalive 32;，但数值不宜超过后端连接池上限（如 Tomcat maxConnections=1000，则 keepalive ≤ 900） - 务必配
proxy_http_version 1.1;和proxy_set_header Connection "";，否则 HTTP/1.0 会导致连接无法复用，least_conn 失去意义 - 对有连接上限的后端，用
max_conns=900主动限流，防止 Nginx 还在往快满的节点上塞连接
配合 slow_start 避免冷启动冲击
刚恢复的节点如果立刻承接 full 流量，容易因缓存未热、连接池未建满而再次超时，形成震荡。
- 给 server 加
slow_start=30s;，让流量在 30 秒内线性上升 - 该参数仅对刚从 down 状态恢复的节点生效，不影响正常运行中的调度逻辑
- 搭配
max_fails=2 fail_timeout=15s，确保故障隔离期足够服务自愈
