Nginx 中 Upstream 如何优化长连接超时参数减少频繁建链开销

Nginx upstream 长连接复用需三超时对齐：keepalive_timeout 比后端 idle timeout 小 5～10 秒，proxy_read_timeout 要远小于 client_*_timeout 且单独调低，connect_timeout 按网络环境设 1～5 秒；同时必须配置 upstream keepalive、proxy_http_version 1.1 和 proxy_set_header Connection ''，并确保后端返回 Connection: keep-alive。

要让 Nginx upstream 真正复用长连接、减少建链开销，不能只调一个超时值。关键在于 keepalive_timeout、后端 idle timeout、proxy_read_timeout 三者对齐，同时确保连接池有足够空闲连接可复用。

keepalive_timeout 必须比后端 idle timeout 小 5～10 秒

这个参数控制 Nginx 在连接池中保留空闲连接的时间。设得太大，连接可能被后端先关闭，Nginx 下次复用时才发现失效，触发重连；设得太小，连接还没来得及复用就被回收。

1. Tomcat 默认 connectionTimeout=60s → Nginx keepalive_timeout 建议设 30～45s
2. Node.js/Go 默认 keep-alive 超时通常为 50～120s → Nginx 可设 40～90s
3. MySQL（stream 模块）默认 wait_timeout=28800 → keepalive_timeout 设 60s 更稳妥

proxy_read_timeout 不等于 keepalive_timeout，要单独调低

它控制 Nginx 从后端读取响应头或数据的等待间隔，和连接空闲无关。若该值过大（如默认 60s），一次慢响应就会卡住整个连接，导致后续请求排队、连接池“假性枯竭”。

1. 普通 API 接口建议设 10～20s
2. 流式响应或大文件下载可放宽至 30～60s，但不宜超过后端实际处理上限
3. 必须确保它远小于 client_header_timeout 和 client_body_timeout，防止客户端已断开而 Nginx 还在等后端

connect_timeout 要足够短，避免建连阻塞堆积

当 upstream 连接池为空或不足时，Nginx 需新建 TCP 连接。如果网络延迟高或后端偶发卡顿，connect_timeout 过长会让大量请求堆积在“建连中”状态。

1. 同机房部署：设 1～3s
2. 跨可用区或跨云：设 3～5s
3. 不建议设为 0 或过长（如 30s），否则会放大故障影响面

配套动作不能少：池子建好，路也得通

光调超时没用。以下三项必须同时满足，keepalive 才真正生效：

1. upstream { keepalive 32; } —— 放在 upstream 块内，按 worker 数与后端能力合理设值
2. proxy_http_version 1.1; 和 proxy_set_header Connection ''; —— 放在 location 中，强制走 HTTP/1.1 并清空干扰头
3. 后端返回响应头含 Connection: keep-alive —— 检查日志或 curl -v 验证，排除中间设备（如 WAF、LB）静默改写