启用upstream长连接是解决Nginx与后端频繁建连导致延迟的最直接手段，需在upstream块配keepalive、location中设proxy_http_version 1.1和proxy_set_header Connection ''，并匹配后端keep-alive超时及系统内核参数优化。
后端集群连接建立延迟，多数不是网络或后端本身慢，而是 Nginx 与后端之间频繁新建短连接导致的。关键在于减少连接创建频次、提升复用效率，并避免端口资源卡死。
启用并调优 upstream 长连接
这是最直接有效的手段。默认情况下，Nginx 每次请求都新建 TCP 连接，而每个连接关闭后会进入 TIME_WAIT 状态，大量短连会快速耗尽本地端口。
- 在 upstream 块中配置
keepalive，建议设为 32 或 64（视并发量调整）：upstream backend { server 10.10.2.3:8080; keepalive 32; } - 在 location 中强制使用 HTTP/1.1 并清除 Connection 头：
proxy_http_version 1.1;<br>proxy_set_header Connection "";
- 确保后端服务（如 Spring Boot、Tomcat）也开启 keep-alive，且超时时间 ≥ Nginx 的 keepalive 设置，否则连接可能被单方面断开
匹配后端连接行为的超时设置
如果后端响应慢或存在长任务，Nginx 默认超时会中断连接，触发重试或失败，间接拉长用户感知延迟。
-
proxy_connect_timeout：控制建连阶段等待时间，建议设为 5–30 秒（根据网络质量调整） -
proxy_read_timeout：适用于流式响应或异步接口，可设为 60–300 秒；WebSocket 场景需设为 86400 -
proxy_send_timeout：影响大请求体上传，一般设为与 read 相近或略小
缓解 TIME_WAIT 压力的内核协同优化
即使开了长连接，健康检查、异步回调等仍会产生短连。此时需系统层配合释放端口资源。
- 开启时间戳和端口复用：
net.ipv4.tcp_timestamps = 1<br>net.ipv4.tcp_tw_reuse = 1
注意：仅对 Nginx 主动发起的 outbound 连接生效，且目标四元组需有变化 - 扩大本地端口范围：
net.ipv4.ip_local_port_range = 1024 65535
将可用端口从约 3.2 万扩至 6.4 万 - 加快中间状态清理：
net.ipv4.tcp_fin_timeout = 30
缩短 FIN_WAIT_2 等状态等待，减少堆积 - 提高 TIME_WAIT 桶上限：
net.ipv4.tcp_max_tw_buckets = 200000
防止桶满丢包 - 务必禁用
tcp_tw_recycle：net.ipv4.tcp_tw_recycle = 0
该参数在 NAT 或云环境极易引发连接失败
验证是否真为连接瓶颈
别盲目调参。先用三行命令快速定位：
-
ss -s | grep time-wait—— 查看 TIME_WAIT 数量是否远高于 established（例如 tw: 25000 vs estab: 500） -
cat /proc/sys/net/ipv4/ip_local_port_range—— 确认端口范围是否受限 -
ss -tan state time-wait | head -5 | awk '{print $5}'—— 观察目标 IP+端口是否高度集中，判断是否某后端节点异常
