必须显式配置upstream keepalive，因Nginx默认不复用后端连接，导致频繁建连、CPU开销高、TIME_WAIT堆积及延迟升高；需合理设置keepalive、keepalive_requests和keepalive_timeout参数，并配合proxy_http_version 1.1等头部配置确保复用生效。
在Nginx反向代理场景中，启用并合理配置Keepalive连接池，能显著降低后端建连开销、提升吞吐量、减少TIME_WAIT堆积，但默认配置往往不够用，需结合业务特征调优。
为什么必须显式配置upstream keepalive Nginx默认对每个请求都新建后端TCP连接（HTTP/1.1虽支持keepalive，但Nginx upstream不自动复用），频繁短连接会导致：• 后端服务CPU消耗集中在SSL握手和TCP三次握手• 客户端并发高时，后端出现大量TIME_WAIT连接• 网络延迟敏感型接口（如API网关）P95延迟明显抬升只有通过keepalive指令显式开启连接池，Nginx才缓存空闲连接供后续请求复用。
关键参数设置与取值逻辑keepalive N：单个worker进程为该upstream维护的空闲长连接最大数量• 建议值 = 后端单实例能稳定承载的并发连接数 × 0.6～0.8• 例如后端Tomcat maxConnections=200，则设为120～160，避免上游连接数超过后端处理能力keepalive_requests N：单个keepalive连接最多承载多少次请求后主动关闭• 默认100，建议调大至1000～10000（取决于后端是否支持HTTP/1.1 pipelining及连接稳定性）
• 过小会频繁断连重连；过大可能因连接空闲超时被后端主动断开keepalive_timeout N：空闲连接在Nginx连接池中保留多久（秒）
• 必须小于后端服务的keepalive timeout（如Nginx设60s，后端至少设75s）
• 生产环境推荐30～60s，兼顾复用率与连接新鲜度配套HTTP头与协议细节不可忽略仅配置keepalive还不够，还需确保请求真正走复用路径：• 在location块中显式添加proxy_http_version 1.1;（HTTP/1.0不支持keepalive）
• 添加proxy_set_header Connection '';清除客户端传来的Connection: close头，防止Nginx误判• 若后端是gRPC或HTTP/2服务，需改用grpc_pass或升级到支持h2的upstream（keepalive对h2同样生效）
• 检查后端响应头是否含Connection: keep-alive，若返回close，Nginx将不复用该连接验证与压测要点优化是否生效，不能只看配置，要实测：• 使用ss -tnp | grep :port | wc -l观察Nginx到后端的ESTABLISHED连接数是否稳定在keepalive设定值附近• 用wrk或hey发起持续压测（如-w 30s -c 200），对比开启前后端连接数、平均延迟、错误率变化• 查看Nginx日志中的$upstream_addr字段，确认复用连接显示为x.x.x.x:y #n格式（#n表示第n次复用）
• 注意监控后端的CLOSE_WAIT连接数——若突增，说明Nginx未及时关闭异常连接，需检查keepalive_timeout与后端超时是否匹配