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 下次复用时才发现失效，触发重连；设得太小，连接还没来得及复用就被回收。
- Tomcat 默认
connectionTimeout=60s→ Nginx keepalive_timeout 建议设 30～45s - Node.js/Go 默认 keep-alive 超时通常为 50～120s → Nginx 可设 40～90s
- MySQL（stream 模块）默认
wait_timeout=28800→ keepalive_timeout 设 60s 更稳妥
proxy_read_timeout 不等于 keepalive_timeout，要单独调低
它控制 Nginx 从后端读取响应头或数据的等待间隔，和连接空闲无关。若该值过大（如默认 60s），一次慢响应就会卡住整个连接，导致后续请求排队、连接池“假性枯竭”。
- 普通 API 接口建议设 10～20s
- 流式响应或大文件下载可放宽至 30～60s，但不宜超过后端实际处理上限
- 必须确保它远小于
client_header_timeout和client_body_timeout，防止客户端已断开而 Nginx 还在等后端
connect_timeout 要足够短，避免建连阻塞堆积
当 upstream 连接池为空或不足时，Nginx 需新建 TCP 连接。如果网络延迟高或后端偶发卡顿，connect_timeout 过长会让大量请求堆积在“建连中”状态。
- 同机房部署：设 1～3s
- 跨可用区或跨云：设 3～5s
- 不建议设为 0 或过长（如 30s），否则会放大故障影响面
配套动作不能少：池子建好，路也得通
光调超时没用。以下三项必须同时满足，keepalive 才真正生效：
-
upstream { keepalive 32; }—— 放在 upstream 块内，按 worker 数与后端能力合理设值 -
proxy_http_version 1.1;和proxy_set_header Connection '';—— 放在 location 中，强制走 HTTP/1.1 并清空干扰头 - 后端返回响应头含
Connection: keep-alive—— 检查日志或 curl -v 验证，排除中间设备（如 WAF、LB）静默改写
