核心是启用并精调stream模块upstream keepalive连接池，配置keepalive 32、keepalive_timeout 60s、proxy_buffering off，禁用proxy_responses 1，引导客户端复用连接，并通过监控指标验证复用效果。
优化 Nginx TCP 代理的流量转发处理流程，核心是减少连接开销、提升复用率、保障稳定性，而不是单纯调高并发数。关键不在“压测能扛多少”，而在“每条连接是否被高效复用”。
启用并精调 stream 模块连接池
stream 模块默认不开启连接复用，必须显式配置 upstream 的 keepalive 才能复用到后端的 TCP 连接：
- 在 upstream 块中设置 keepalive 32（数值建议为单台后端最大连接数的 1/2～1/3，避免压垮后端）
- 搭配 keepalive_timeout 60s，防止空闲连接长期滞留占用资源
- 务必声明 proxy_buffering off（stream 模块默认关闭，但显式写出更可靠），避免缓冲引发粘包或延迟
- 禁用 proxy_responses 1（仅适用于 Redis/MySQL 等单请求单响应协议）；长连接服务应设为 0 或直接省略
合理设计客户端连接行为
Nginx 不控制客户端，但网关部署方式直接影响复用效果：
- 对外提供稳定 VIP + 固定端口，避免客户端因 DNS 轮询或服务发现误判而频繁重连
- Java 客户端推荐使用 Netty ChannelPool 或 HikariCP（MySQL 场景），而非每次 new Socket
- 客户端 connect/read timeout 不宜过短（如低于 5s），否则易触发重建连接，抵消复用收益
- Linux 客户端可启用 net.ipv4.tcp_tw_reuse = 1，配合扩大 ip_local_port_range 缓解 TIME_WAIT 压力
按需配置动态路由与健康检查
对有业务逻辑的 TCP 流量（如按地域、租户分流），不应依赖简单轮询：
- 用 hash $remote_addr 或 hash $binary_remote_addr 实现 IP 一致性哈希，保障会话黏性
- 为 upstream 配置 max_fails=2 fail_timeout=30s，自动剔除不可用节点
- 未匹配路由规则时，指定 default_server 作为兜底后端，避免连接失败
- 开启 proxy_protocol on（配合支持 PROXY 协议的后端），透传真实客户端 IP
验证复用是否真正生效
配置完不等于优化到位，需通过指标交叉验证：
- 查 Nginx 状态：stream_upstream_connections_active 和 stream_upstream_connections_idle 应远小于客户端并发连接数
- 比对后端服务器 ss -s | grep "TCP:" 中 established 数量，若明显低于客户端数，说明复用成功
- 紧盯 error log：出现 connect() failed (111: Connection refused) 多是连接池不足；upstream timed out 则需排查后端响应慢或超时设置过短
- 避免只看“是否通”，要盯住连接生命周期——理想状态下，单个 upstream 连接应服务多个客户端会话
