合理规划 upstream 的 keepalive 值需根据后端单实例并发能力、Nginx worker 数量及安全水位反向推算，推荐值≈后端稳定并发×0.6～0.8÷worker数，并匹配后端真实限制（如 Go 默认每主机仅2空闲连接），同时配合 least_conn 等负载策略缓解连接倾斜。
合理规划 upstream 中的 keepalive 数值，核心不是看并发峰值或拍脑袋定个大数，而是根据后端服务的实际承载能力、Nginx worker 进程数量和安全水位反向推算。设得过小，连接池形同虚设，仍频繁建连；设得过大，可能耗尽后端文件描述符（fd）或触发 RST，反而降低稳定性。
按后端单实例能力反推
keepalive 后的数字表示：每个 worker 进程对该 upstream 中每台后端服务器最多缓存的空闲长连接数。它不等于总连接上限，也不直接对应 QPS。
- 公式建议：keepalive ≈ 后端单实例稳定并发连接数 × 0.6～0.8 ÷ worker 进程数
- Tomcat 默认
maxConnections=200，4 个 worker → 推荐设keepalive 32或48 - Node.js / Go 类服务，默认连接池宽松，但实际受 I/O 和事件循环限制，建议先按
200～400总连接数起步，再除以 worker 数 - Windows 或内存受限环境，
32～64是更稳妥的起点
匹配后端真实限制，避免“池大无用”
数值再大，也得后端接得住。否则 Nginx 尝试复用时会被拒绝或重置：
- 若后端是 Go（
http.Server.MaxIdleConnsPerHost默认仅 2），Nginx 设keepalive 100没意义——多数连接根本连不上 - 若后端是 Tomcat，需确认
connectionTimeout（如设为 60s），Nginx 的keepalive_timeout应设为 30～45s，防止持有已失效连接 - 后端返回
Connection: close（常见于错误响应、WAF 干预、调试开关开启），该连接立即释放，无法进入池中复用
结合负载策略缓解连接倾斜
长连接复用容易导致某台后端被“粘住”，其他节点空闲。尤其在使用 ip_hash 或客户端连接长期存在时：
- 优先考虑
least_conn：动态选择当前活跃连接最少的后端，更适配 keepalive 场景 - 若必须用
ip_hash，可配合hash $remote_addr consistent;减少节点增减时的连接震荡 - 避免单一后端因复用过度而堆积大量空闲连接，影响整体吞吐弹性
