least_conn算法需配合keepalive、协议头处理和超时设置才能有效解决长连接负载不均；须在upstream中启用least_conn、配置max_conns、keepalive，location中透传长连接，合理设置各类超时，并补全健康检查。
直接用 least_conn 算法是解决长连接业务下后端负载不均最有效的方式，但它不是单独开个指令就完事——必须配合 keepalive、协议头处理和超时设置，才能让连接数统计真实、调度逻辑生效。
基础配置要写对这三处
在 upstream 块中启用 least_conn 的同时，注意以下关键点：
- 首行直接写
least_conn;，不加参数，也不和weight混用（Nginx 会忽略 weight） - 每个
server行可配max_conns实现软性容量分级，比如高性能节点设max_conns=2000，普通节点设800 - 必须加上
keepalive N;（建议 16–32），否则连接频繁新建，活跃连接数无法稳定反映真实负载
HTTP 层必须支持长连接复用
如果后端是 HTTP 服务，光有 upstream 配置还不够，location 中还要显式开启长连接透传：
- 设置
proxy_http_version 1.1; - 清除 Connection 头：
proxy_set_header Connection ''; - 后端本身需支持 keep-alive，如 Spring Boot 默认开启，Tomcat 要检查
keepAliveTimeout配置
超时设置要匹配业务特征
长连接场景下，超时不合理会导致连接“假占位”，干扰 least_conn 判断：
-
proxy_read_timeout至少等于后端最长预期处理时间（例如文件上传或报表导出设为 300 秒） -
keepalive_timeout全局建议设为 65 秒，兼顾复用率与及时释放空闲连接 - 避免
proxy_connect_timeout过短（如低于 1 秒），否则健康检查易误判
补全健康检查，防止“假活”节点吸流
least_conn 不自动剔除故障节点，必须手动配置健康探测：
- 每个
server加上max_fails=2 fail_timeout=10s，连续失败 2 次暂停 10 秒 - 若后端提供
/health接口，推荐编译安装nginx_upstream_check_module做主动 HTTP 探测 - 用
down或backup标记保留人工干预入口，便于紧急隔离
