Nginx长连接调优需协同配置keepalive_timeout、keepalive_requests及upstream keepalive参数：前者控制空闲连接关闭时机（建议30–300s，略小于客户端值），后者限制单连接请求数（默认100，可调至50–5000），upstream需启用keepalive并匹配后端超时与连接数限制，调优后须通过stub_status、ss命令及抓包验证复用效果。
在高并发API场景下，Nginx的长连接（Keepalive）超时参数直接影响连接复用率、资源占用和响应延迟。调优核心是平衡连接复用收益与空闲连接堆积风险，避免因超时设置不合理导致TIME_WAIT激增、端口耗尽或客户端502/504错误。
keepalive_timeout：控制服务端主动关闭空闲连接的时机
该参数定义Nginx保持客户端长连接的最大空闲时间，单位秒。默认值通常为65s，但在高并发API场景中常需调整：
- 若上游API响应快、客户端连接频繁复用（如移动端App、前端SPA），可适当延长至120–300s，提升复用率，降低TCP握手开销；
- 若后端处理延迟波动大、或客户端存在“假长连接”（如弱网下未及时发请求但连接未断），建议缩短至30–60s，避免大量空闲连接占满worker_connections；
- 注意：该值应略小于客户端（如浏览器、OkHttp、axios）的keep-alive timeout，否则Nginx会先断连，导致客户端误判为异常中断。
keepalive_requests：限制单连接最大请求数
防止单个长连接持续占用资源过久，尤其适用于请求体大、或存在内存泄漏风险的旧版上游服务：
- 默认100，对纯JSON API通常足够；若接口轻量且稳定，可调高至1000甚至5000，减少连接重建频率；
- 若发现Nginx日志中频繁出现"client closed connection while waiting for request"或上游偶发超时，可尝试降低至50–200，强制连接轮转，缓解潜在连接老化问题；
- 该值不触发TCP断开，仅在达到后标记连接为“可关闭”，实际断开仍受keepalive_timeout约束。
upstream keepalive相关参数：复用到后端的连接池
仅配置客户端侧不够，还需开启并调优到上游服务（如Go/Java微服务）的长连接池：
-
upstream中启用keepalive：
keepalive 32;（表示每个worker进程最多缓存32个空闲到上游的连接）； -
配合proxy_http_version 1.1和Connection头：
proxy_http_version 1.1; proxy_set_header Connection '';，确保不透传Connection: close； -
keepalive_timeout也作用于上游：可在upstream块内单独设
keepalive_timeout 60s;，建议与后端服务的keepalive设置一致，避免单方面断连； - 注意：keepalive数量不宜超过后端单实例能承载的并发连接数，否则可能引发后端连接拒绝（如Tomcat maxConnections超限）。
配套检查与验证要点
调优后需结合指标确认效果，而非仅看配置生效：
- 监控
nginx_stub_status中的Active connections与Reading/Writing/Waiting比例，Waiting长期偏高可能说明keepalive_timeout过长或后端响应慢； - 用
ss -ant | grep :80 | wc -l观察ESTABLISHED连接数趋势，对比调优前后是否显著下降（说明复用率提升）或突增（可能timeout太短导致重连风暴）； - 抓包验证：客户端发起两次请求，检查第二请求是否复用同一TCP流（源端口不变），且无SYN/SYN-ACK往返；
- 检查error.log中是否有"upstream prematurely closed connection"，常因upstream keepalive_timeout
