nginx高并发连接重用核心是复用nginx与后端的连接，而非客户端连接；http场景启用upstream keepalive，tcp/udp场景用stream模块keepalive，需配套调优超时、缓冲及客户端协同，并通过状态页、指标和日志验证复用效果。
优化 Nginx 在高并发场景下的连接重用逻辑，核心不是让客户端“反复连 Nginx”，而是让 Nginx 尽可能复用它与后端服务之间的连接，从而大幅降低建连开销、减少 TIME_WAIT、提升吞吐稳定性。关键在于分清层级：客户端→Nginx 是接入层连接管理；Nginx→上游是连接池复用主战场。
HTTP 场景：启用 upstream keepalive 连接池
这是最常用也最有效的重用机制，适用于 HTTP/1.1 和 HTTP/2：
- 在
upstream块中显式声明keepalive 32;（数值建议为单台后端最大并发连接数的 1/2～1/3） - 配套设置
keepalive_timeout 60s;，避免空闲连接长期滞留占用资源 - 确保后端服务支持 HTTP Keep-Alive，并返回
Connection: keep-alive及合理Keep-Alive: timeout=60, max=1000 - 若使用长连接协议（如 gRPC over HTTP/2），需额外配置
http2_max_requests控制单连接请求数上限
TCP/UDP 场景：用 stream 模块 + keepalive 复用后端链路
适用于 Redis、MySQL、自定义 TCP 服务等非 HTTP 流量：
- 确认 Nginx 编译时启用了
--with-stream，并在配置中启用stream { ... }块 - upstream 内必须加
keepalive 32;和keepalive_timeout 60s;，否则默认每次请求都新建后端连接 - 关闭缓冲：
proxy_buffering off;（stream 模块默认关，但显式声明更稳妥），防止粘包或延迟 - 根据协议类型设
proxy_responses 1（短会话，如 MySQL 查询）或省略/设为0（长连接，如 WebSocket 代理）
客户端协同：引导而非强制复用
Nginx 不控制客户端行为，但可通过设计减少其断连动机：
- 对外暴露稳定 VIP 或域名，禁用 DNS 轮询式负载均衡，避免客户端因解析变化主动重建连接
- 后端服务发现应走长连接友好的机制（如基于 gRPC 的 xDS 或 Consul Health Check），而非定时刷新 IP 列表
- 客户端侧需使用带连接池的 SDK（如 Java 的 Netty ChannelPool、Go 的 http.Transport.MaxIdleConns）
- 避免客户端设置过短的
connect timeout或read timeout，尤其在弱网下易触发误断连
验证与监控：确认复用真正生效
配置完不等于跑通，必须通过指标交叉验证：
- 查 Nginx 状态页：
Active connections高但Writing低、Waiting占比高，说明连接复用正常 - 用
nginx-vts-exporter观察nginx_vts_upstream_connections_idle是否持续存在且数量稳定 - 对比后端服务器
ss -s | grep "TCP:"中的 established 数，应显著低于客户端并发总数 - 检查 error log 是否频繁出现
upstream timed out或connect() failed (111)，这往往意味着连接池枯竭或后端响应慢拖垮复用链路
