怎么在 Nginx 里优化高可用负载均衡器的连接状态管理

优化Nginx高可用负载均衡连接状态管理需协同管控客户端—Nginx—后端三段连接：区分并独立配置三类连接超时与数量，采用least_conn算法结合连接数感知调度，启用主动健康检查驱动状态收敛，并协同worker进程压测调优资源。

优化 Nginx 高可用负载均衡器的连接状态管理，核心是让连接“可复用、可感知、可收敛”。不是简单调大超时值或堆连接数，而是围绕客户端—Nginx—后端三段连接生命周期做协同控制，尤其要避免因状态不一致导致的连接堆积、请求阻塞或节点过载。

精准区分三类连接并独立配置

Nginx 中实际存在三类关键连接：客户端到 Nginx 的连接、Nginx 到后端的连接、以及连接池内部的空闲连接。它们生命周期不同，必须分开管理：

• 客户端连接：由 keepalive_timeout 和 keepalive_requests 控制，建议设为 keepalive_timeout 75s（略小于后端服务的 idle timeout），keepalive_requests 100（HTTP/1.1）或 http2_max_requests 200（HTTP/2）；
• Nginx→后端连接：由 upstream 块中的 keepalive N 指令定义，表示每个 worker 进程最多缓存 N 个空闲长连接，推荐值为后端单节点平均并发连接数的 1.2 倍（如后端均值 500，则设 keepalive 600）；
• 连接池空闲连接：受 keepalive_timeout（upstream 级）影响，需显式配置，例如 upstream backend { keepalive 64; keepalive_timeout 60s; }，避免空闲连接长期滞留占用 fd。

用 least_conn + 连接数感知替代轮询

对于长连接场景（如 WebSocket、gRPC、API 网关），轮询算法完全无法反映真实负载。Nginx 的 least_conn 会实时统计每个后端当前活跃连接数，并优先将新连接分发给最少的一方，大幅缓解倾斜问题：

• 必须配合 proxy_http_version 1.1 和 proxy_set_header connection ""，确保上游连接真正复用；
• 若后端有连接上限（如 Tomcat maxConnections=1000），可在 upstream 中用 max_conns=900 主动限流，防止打满；
• 注意：该算法只统计“已建立且未关闭”的连接，不包含正在握手或已超时待回收的连接，因此需搭配健康检查共同生效。

主动健康检查驱动连接状态收敛

被动检查（靠请求失败触发）会让坏节点持续承接连接，直到大量请求超时。高可用场景必须启用主动探测，让连接状态快速对齐后端真实可用性：

• 在 upstream 中配置 max_fails=2 fail_timeout=15s，避免单次抖动误判；
• 引入 nginx-upstream-check-module，每 3 秒向 /healthz 发起 HEAD 请求，连续失败 3 次即标记 down，并立即关闭所有指向该节点的空闲连接；
• 后端健康接口应轻量（仅校验进程存活+监听端口），禁用依赖数据库或远程服务的全链路检测，否则健康检查本身会成为瓶颈。

连接资源与 worker 协同压测调优

连接状态管理最终受限于系统资源，需结合 worker 进程模型统一调优：

• worker_processes auto + worker_connections 10240 是常见起点，但总连接容量 ≈ worker_processes × worker_connections；
• 每个长连接至少占用 1 个 fd 和少量内存，keepalive 值过高会导致 fd 耗尽（尤其当后端节点多时），建议用 lsof -p $(pgrep nginx) | wc -l 实时监控；
• 压测时重点观察：Nginx 的 Active connections（来自 stub_status）、各后端的 ESTABLISHED 连接数、以及 nginx -t 报出的 “could not build the server_names_hash” 类错误——这往往是 hash 表溢出，需调大 server_names_hash_max_size 或 server_names_hash_bucket_size。