要真正提升前后端全链路网络交互效率，必须协同控制客户端→Nginx→后端三段长连接：客户端需主动发起keep-alive，Nginx须配齐proxy_http_version 1.1、proxy_set_header Connection ''和upstream keepalive三项，后端空闲超时须大于Nginx的keepalive_timeout且禁用Connection: close。

要真正提升前后端全链路的网络交互效率，不能只在 Nginx 或后端单点调优，而需从客户端 → Nginx（反向代理）→ 后端服务三段协同控制长连接行为。关键在于每一段的 keepalive 配置必须对齐：协议版本一致、连接头不干扰、空闲超时有梯度、连接池容量合理。缺任何一环，复用就会中断，变成“纸面长连接”。

客户端侧：确保浏览器或 SDK 主动复用连接

客户端是长连接发起方，若它默认关闭 keep-alive，后续所有优化都无效。

• 现代浏览器默认启用 HTTP/1.1 keep-alive，但部分旧版或特殊环境（如某些 Electron 应用、curl 默认行为）可能仍走 HTTP/1.0 或主动加 Connection: close
• 可通过 Chrome DevTools → Network → Headers 查看请求是否带 Connection: keep-alive，响应头是否含该字段且无 Connection: close
• 前端 SDK（如 axios、fetch）无需额外配置；但若用老版 httpClient（Java），需显式设置 maxConnectionsPerRoute 和 keepAliveStrategy
• 移动端 WebView 或小程序需确认其底层网络栈是否支持持久连接（如 Android WebView 67+、iOS WKWebView 均默认支持）

Nginx 反向代理层：启用并精准控制 upstream 连接池

这是全链路中最常出错的一环——很多人只配了 upstream keepalive 32，却忘了 proxy 层必须配合协议升级和头清理。

• 在 upstream 块中声明连接池：keepalive 64;（建议值：后端单实例稳定并发 × 0.7 ÷ worker 进程数）
• 配套设置生命周期：keepalive_requests 1000;（避免默认 100 导致频繁断连），keepalive_timeout 30s;（必须比后端空闲超时短至少 15 秒）
• 在 location 或 server 块中启用协议与清理头：proxy_http_version 1.1; + proxy_set_header Connection '';
• 禁用自动注入：不手动加 Keep-Alive 头，Nginx 会根据 upstream 自动协商

后端服务端：匹配 Nginx 行为，不主动截断连接

后端才是连接生命周期的最终裁决者。Nginx 想复用，后端却已关，复用就失败。

• Tomcat：检查 connectionTimeout ≥ 45s（若 Nginx 设 30s），maxKeepAliveRequests ≥ 1000；禁用 disableUploadTimeout 等干扰项
• Node.js（Express/Koa）：设置 server.keepAliveTimeout = 45000，server.headersTimeout = 60000
• Go（net/http）：配置 http.Server.IdleTimeout = 45 * time.Second，ReadTimeout / WriteTimeout > IdleTimeout
• 验证响应头：确保返回中不含 Connection: close，且明确支持 HTTP/1.1（HTTP/2 不需 Connection 头，但 keepalive 仍生效）

验证是否真正生效：别信配置，要看连接状态

压测前必须实证，否则优化等于没做。

• 查 Nginx 到后端的活跃连接数：ss -tan | grep :8080 | grep ESTAB | wc -l，应稳定在 keepalive 值 × worker 数 的 70%~90%
• 抓包看建连频率：tcpdump -i any port 8080 -nn -c 50，若大量重复 SYN，说明复用未生效
• 观察后端 TIME_WAIT：ss -s | grep -i time，开启 keepalive 后应明显下降（降幅通常达 60% 以上）
• Nginx debug 日志中搜索 "reuse connection" 或 "create connection"，确认复用占比