要让Nginx在大吞吐量场景下高效复用连接，核心是协同调优upstream连接池、proxy_http_version 1.1、proxy_set_header Connection ""、keepalive_timeout、keepalive_requests及后端keep-alive响应，缺一不可；否则配置无效。
要让 Nginx 在大吞吐量场景下高效保持连接，核心不是“开不开 keepalive”，而是构建一套协同工作的连接复用体系——上游连接池、协议版本、头部控制、超时策略必须同步调优，否则配置了也白配。
upstream 连接池必须显式启用并合理设值
Nginx 默认对每个请求都新建后端 TCP 连接，不自动复用。高并发下会导致后端频繁握手、TIME_WAIT 堆积、P95 延迟跳升。必须在 upstream 块中加 keepalive N 指令：
- N 值建议 = 后端单实例稳定并发数 × 0.6～0.8。例如 Tomcat maxConnections=200，就设为 120～160；过高会压垮后端，过低仍频繁建连
- 该值是每个 worker 进程维护的空闲连接上限，不是全局总数。若启用了 4 个 worker，实际最多可缓存 4×N 条连接
- 搭配 least_conn 负载算法更稳妥，避免长连接集中在少数节点上造成堆积
HTTP 协议与请求头必须匹配复用逻辑
仅写 keepalive 不足以触发复用，客户端和 Nginx 都得“说同一种话”：
- location 中必须写 proxy_http_version 1.1 —— HTTP/1.0 不支持 keep-alive
- 必须加 proxy_set_header Connection ''，清除客户端可能带的 Connection: close 头，否则 Nginx 会误判并断开复用路径
- 检查后端响应头是否含 Connection: keep-alive；若返回 close 或缺失，Nginx 就不会把该连接放回池中
- 后端服务（如 Spring Boot 内嵌 Tomcat）的 keepAliveTimeout 必须 > Nginx 的 keepalive_timeout，否则连接会被后端先断
三个 timeout 参数需分层协同设置
连接生命周期由三类超时共同约束，不能孤立调整：
- keepalive_timeout：空闲连接在 Nginx 连接池中保留多久（秒）。生产推荐 30～60s，必须比后端小 5～15 秒
- keepalive_requests：单条 keepalive 连接最多承载多少次请求。建议 1000～10000，过小导致连接反复关闭重建；过大可能因后端空闲超时而失效
- proxy_read_timeout 和 proxy_send_timeout：控制单次请求的读写等待上限，应略小于后端处理超时（如后端设 300s，Nginx 可设 280s），防止 Nginx 主动中断正在处理的长耗时请求
配套系统级参数不可忽略
连接复用效果最终受限于底层资源和内核行为：
- 确保 worker_connections 足够大（如 10240），且系统 ulimit -n ≥ worker_processes × worker_connections
- 开启 tcp_nodelay on（尤其对 API/实时接口），避免 Nagle 算法引入毫秒级延迟
- 静态资源多的场景可配 sendfile on + tcp_nopush on，提升文件传输效率
- Linux 下 events 块启用 use epoll 和 multi_accept on，提升高并发连接接收效率
