长连接负载均衡关键在于稳连接、匀分配、延寿命；需分别优化客户端与后端keepalive参数、选用least_conn等适配算法、强化双模健康检查、精简协议与日志。
处理长连接负载均衡，关键不在“多建连接”，而在“稳住连接、分得均匀、活得长久”。Nginx 集群中若未针对性优化，容易出现后端连接堆积、部分节点过载、首字节延迟升高、健康检查失灵等问题。
精准控制上下游长连接生命周期
客户端与 Nginx、Nginx 与后端之间需分别管理长连接，且参数要错开、协同：
- 客户端侧：通过
keepalive_timeout 75s（建议 60–120s）和keepalive_requests 100控制单连接最大请求数，避免连接长期空闲占用资源 - 后端侧：Nginx upstream 中必须配置
keepalive 32（数值 ≈ 单 worker 并发请求峰值的 1/3～1/2），显式开启连接池；同时确保后端服务（如 Tomcat、Spring Boot）的 keep-alive 超时略大于 Nginx 的proxy_read_timeout - 协议协同：location 块中强制写
proxy_http_version 1.1和proxy_set_header Connection ""，防止客户端传来的Connection: keep-alive被错误透传到后端引发复用失败
选用适配长连接的调度算法
轮询（round-robin）在长连接场景下易导致连接数倾斜——因为连接一旦建立就持续复用，后续请求仍打向同一后端。应根据业务特征选型：
- 高并发 API 网关、WebSocket 推送等：优先用
least_conn，它按实时活跃连接数分配，天然适配长连接生命周期 - 需会话保持但又怕 IP 分布不均（如 NAT 环境）：改用
hash $remote_addr consistent，一致性哈希比ip_hash更抗节点伸缩，避免扩缩容时大量连接重散列 - 避免在公网或混合云链路中使用
ip_hash：大量用户共用出口 IP，会导致严重连接倾斜
强化健康检查以匹配真实网络状态
默认被动检查（靠请求失败触发）在跨机房、高延迟链路中反应滞后，可能让故障节点持续承接长连接数分钟之久：
- 主动检查要放宽超时：例如
health_check interval=10s fails=3 passes=2 match=status_2xx timeout=8s，其中timeout应设为实测链路 P99 RTT 的 1.5 倍 - 启用双模式保障：被动检查（
max_fails=2 fail_timeout=15s）兜底 + 主动检查独立运行，两者互不干扰，既防误杀也保恢复速度 - 健康检查路径务必直连后端内网地址，不走公网、不绕代理、不经过其他中间层，否则检测结果无法反映真实服务状态
精简协议开销与日志负担
长连接下每个请求的协议解析、头信息透传、日志记录都会被放大数十甚至上百倍：
- 关闭非必要头：用
proxy_set_header X-Forwarded-For ""或按需透传，避免冗余字段堆积 - 压缩响应体：对文本类接口启用
gzip on并合理设置gzip_types，降低传输量，间接减少连接等待时间 - 收敛访问日志：长连接场景下，单个连接承载多个请求，建议关闭 access_log 或仅记录关键字段（如 status、upstream_addr、request_time），避免 I/O 成瓶颈
