优化Nginx长连接需分两段：客户端到Nginx用keepalive_timeout（15–60秒）和keepalive_requests（500–2000）控制空闲与请求数；Nginx到后端须在upstream配keepalive N、proxy_http_version 1.1及proxy_set_header Connection ""，三者缺一不可。
优化 Nginx 长连接超时参数，核心是分清“客户端到 Nginx”和“Nginx 到后端”两段连接，分别控制空闲等待、请求承载与连接复用能力。调得准，能大幅减少 TCP 握手/挥手开销；调得偏，反而引发 TIME_WAIT 堆积或连接复用失败。
客户端到 Nginx 的长连接：控制空闲等待与单连请求数
这是浏览器、App 或 SDK 与 Nginx 建立的连接，目标是让一次 TCP 连接服务多个 HTTP 请求。
-
keepalive_timeout：设为 15–60 秒（非默认 65 秒）。第一个值是 Nginx 等待下个请求的上限，第二个值写入响应头
Keep-Alive: timeout=xx。例如keepalive_timeout 30s 25s;—— 服务器最多等 30 秒，同时告诉客户端“你最多可等 25 秒”。移动端 API 可压到 5–15 秒，静态资源可设 10–30 秒。 - keepalive_requests：建议调至 500–2000。默认 100 容易在高 QPS 下频繁断连重建。值过大（如 >5000）可能让低频连接长期占着 fd 不释放，需结合业务请求密度评估。
-
keepalive_disable：现代环境统一设为
none，避免旧 UA 策略干扰长连接启用。
Nginx 到后端 upstream 的长连接池：复用才是关键
这才是降低后端建连压力的主战场。光配前端 keepalive 没用，必须在 upstream 块中显式启用连接池，并匹配协议头清理。
-
upstream keepalive N：放在 upstream 块内，例如
keepalive 64;。它不是最大连接数，而是每个 worker 进程为该 upstream 缓存的空闲长连接上限。建议按后端实例数 × 16～64 设置（如 2 台后端，设 32～64）。 -
proxy_http_version 1.1 和 proxy_set_header Connection ""：必须同时配置在 location 中。前者启用 HTTP/1.1 持久连接能力，后者清除 Nginx 默认注入的
Connection: close，否则后端仍会主动断连。 -
keepalive_requests 与 keepalive_timeout（upstream 级）：可选但推荐。例如
keepalive_requests 500; keepalive_timeout 20s;，让单个上游连接最多处理 500 次请求，空闲 20 秒后回收，兼顾复用率与及时释放。
配套超时参数要对齐后端行为
避免因超时错位导致连接被误杀或挂死。所有超时应形成梯度关系：
- proxy_connect_timeout：只管 TCP 握手，内网设 3–5 秒，跨机房设 5–8 秒，不建议超过 10 秒。
- proxy_read_timeout：必须略大于后端最长业务耗时（如 Redis 批量操作 240s → 设 300s），但上限建议 ≤ 600s，防止单请求拖垮整个连接池。
-
keepalive_timeout（客户端侧） 应 小于后端服务的 keepalive 超时。例如 Tomcat 的
connectionTimeout设 75s，Nginx 就设 60s，确保 Nginx 先关闭空闲连接，而非等后端断。
验证是否真正生效
改完配置不能只 reload 就算完，要确认行为符合预期：
- 临时停掉一台后端，用
curl -v http://your-domain/观察响应延迟是否接近你设的proxy_connect_timeout值。 - 开启
error_log /path/error.log debug;，搜索connect() failed或connection timed out，看触发阶段是否匹配预期。 - 用
tcpdump抓包：若 SYN 发出后无 SYN-ACK 就断开，属 connect 阶段超时；若握手完成却卡住，则是proxy_read_timeout或proxy_send_timeout在起作用。
