nginx负载均衡连接池需upstream keepalive、http/1.1启用和connection头清理三要素协同;keepalive n为每个worker对每server的空闲连接上限;须配proxy_http_version 1.1与proxy_set_header connection "";推荐结合least_conn调度,并通过ss命令及time_wait变化验证效果。

upstream 中启用 keepalive 连接池
这是连接池的核心配置,定义每个 worker 进程对每台后端服务器最多缓存多少个空闲长连接:
- keepalive N 中的 N 是“每个 worker 进程”为“每个 server”维护的空闲连接上限,不是全局总数。例如设为 32,4 个 worker 最多可缓存 128 条空闲连接
- N 值需结合后端单节点平均并发连接数来定,一般取其 0.8~1.2 倍;过小导致频繁建连,过大浪费内存
- 必须放在 upstream 块内,且不能与 proxy_pass 同级
示例:
upstream backend_api {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
keepalive 32;
}
代理层强制使用 HTTP/1.1 并清理 Connection 头
若不显式设置,Nginx 默认以 HTTP/1.0 与后端通信,无法复用连接:
- proxy_http_version 1.1:启用 HTTP/1.1 协议,支持长连接
- proxy_set_header Connection "":清空 Connection 头(不是设为 close),否则 Nginx 可能主动关闭连接
- 这两项必须和 keepalive 配套使用,单独配置无效
示例 location 块内:
location /api/ {
proxy_pass http://backend_api;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
}
搭配 least_conn 实现连接数感知调度
长连接生命周期长,轮询容易造成连接倾斜(部分后端堆积大量连接):
- 在 upstream 中添加 least_conn,Nginx 会实时统计各后端当前活跃连接数,新请求优先发给连接最少的节点
- 这对 WebSocket、gRPC、API 网关等长时连接场景效果明显,实测连接分布偏差可大幅降低
- 注意:least_conn 是调度算法,和 keepalive 不冲突,两者可共存
完整 upstream 示例:
upstream backend_api {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
keepalive 32;
}
验证连接池是否生效
配置完成后需确认是否真正起效,而非仅语法正确:
- 在后端服务器上运行 ss -ant | grep :8080 | grep ESTAB | wc -l,观察活跃连接数是否趋于稳定(不随 QPS 剧烈波动)
- 对比开启前后,后端 TIME_WAIT 数量应明显下降
- 检查 Nginx error 日志,确认无 “upstream connection timed out” 或 “no live upstreams” 类报错











