Nginx转发优化核心是“少建、多用、快通”，需精调upstream连接池、禁用缓冲、适配TCP场景、引导客户端复用，并通过状态指标和日志验证复用效果。
精调 upstream 连接池（HTTP/HTTPS 场景）
对 HTTP 类转发，关键在 upstream 块中启用并控制 keepalive：
- 设置
keepalive 32;（数值建议为单台后端最大连接数的 1/2～1/3，防止压垮后端） - 搭配
keepalive_timeout 60s;，避免空闲连接长期滞留 - 在
location块中显式写proxy_http_version 1.1;和proxy_set_header Connection '';，主动协商长连接 - 禁用缓冲：
proxy_buffering off;（尤其对流式响应或 WebSocket 场景，避免粘包或延迟）
适配 TCP 流量（stream 模块场景）
若代理 Redis、MySQL 或自定义 TCP 服务，需启用 stream 模块并针对性配置：
- 在
stream块中定义upstream，必须显式声明keepalive 32;和keepalive_timeout 60s;，否则默认不复用连接 -
proxy_buffering off;（stream 模块默认关闭，但显式写出更可靠） - 对 Redis/MySQL 等单请求单响应协议，设
proxy_responses 1;；对长连接业务协议（如 MQTT），应设为0或省略 - 开启
proxy_protocol on;（配合支持 PROXY 协议的后端），透传真实客户端 IP
引导客户端合理复用连接
Nginx 不控制客户端，但网关部署方式直接影响复用效果：
- 对外提供稳定 VIP + 固定端口，避免因 DNS 轮询或服务发现误判导致频繁重连
- Java 客户端推荐使用连接池（如 Netty ChannelPool、HikariCP），而非每次 new Socket
- 客户端 connect/read timeout 不宜低于 5s，否则易触发无效重建
- Linux 客户端可启用
net.ipv4.tcp_tw_reuse = 1，并扩大ip_local_port_range缓解 TIME_WAIT 压力
验证复用是否真正生效
配置完不能只看“通不通”，要盯住连接生命周期：
- 查 Nginx 状态：指标
stream_upstream_connections_active和stream_upstream_connections_idle应远小于客户端并发连接数 - 比对后端
ss -s | grep "TCP:"中 established 数量，若明显低于客户端数，说明复用成功 - 紧盯 error log：频繁出现
connect() failed (111: Connection refused)多是连接池不足；upstream timed out则需排查后端响应慢或超时设置过短
