least_conn算法通过将新请求优先分发给当前活跃连接数最少的健康后端，动态缓解任务积压；需配合健康检查、upstream keepalive（如32）及后端连接复用，并用max_conns适配性能差异，再协同超时与重试机制才能真正生效。

Nginx 的 `least_conn` 算法能有效缓解后端任务积压，关键在于它不按顺序派活，而是实时“看谁手头最空”，把新请求直接交给当前活跃连接数最少的后端。 这个机制对积压问题特别管用——当某个节点正在处理耗时任务（比如报表导出、AI推理、大文件上传），它的连接数会持续居高不下；`least_conn` 就会自然绕开它，把后续请求导向空闲或轻载节点，避免雪球越滚越大。 它真正解决的是“隐性过载”：CPU可能不高，响应时间却飙升，监控里看到的是连接堆积而非资源打满。轮询对此无感，而 `least_conn` 一眼就能识别。

怎么让 least_conn 真正起效

光写一行 least_conn; 不够，得配齐三件事：

• 健康检查必须开启：否则宕机但 TCP 连接未断的节点，连接数可能还是 0，Nginx 会继续往里发请求。建议用主动探测：health_check interval=3 fails=2 passes=2，配合状态码和响应体校验
• upstream keepalive 要设合理值：比如 keepalive 32。太小导致频繁建连，太大则空闲长连接虚高连接数，干扰判断。注意：keepalive 连接会计入活跃总数
• 后端要支持连接复用：HTTP/1.1 需返回 Connection: keep-alive，HTTP/2 默认支持；Nginx 侧加上 proxy_http_version 1.1; proxy_set_header Connection '';

应对性能差异大的后端

least_conn 本身不认 weight，但你可以用 max_conns 表达承载力差异：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 高性能节点设 server 10.0.1.10:8080 max_conns=2000;
• 普通节点设 server 10.0.1.11:8080 max_conns=800;
• 超过上限的请求会被跳过，自动选下一个连接数最少且未超限的节点

配合超时与重试防卡死

即使用了 least_conn，如果后端响应慢或失败，请求仍可能滞留。需协同配置：

• proxy_connect_timeout 2s：建连别拖太久
• proxy_read_timeout 15s：略大于业务最长耗时，避免误杀慢请求
• proxy_next_upstream error timeout http_502 http_504：遇到这些错误立即换节点，不重试原路

验证是否真在减少积压

别只看平均响应时间，重点盯这些指标：

• 各后端的 active connections（通过 stub_status 或 Prometheus）是否趋于均衡？是否有个别节点长期接近 max_conns？
• $upstream_header_time 稳定但 $upstream_response_time 持续升高 → 积压发生在后端业务层
• 日志中 $upstream_addr 分布是否随负载变化动态偏移？而不是固定打到某台机器