nginx stream模块不支持客户端侧tcp连接复用，因其工作在四层、不解析应用层协议，无法识别请求边界；但支持upstream连接池复用，需配置keepalive、keepalive_timeout及proxy_buffering off，并确保后端服务支持长连接。
Nginx 的 Stream 模块本身不支持 TCP 连接复用（即客户端复用同一个 TCP 连接发送多个请求），这是由其设计定位决定的：Stream 模块面向的是四层（L4）透传，处理的是原始字节流，不解析应用层协议（如 HTTP、Redis 协议等），因此没有“请求/响应”概念，也无从实现类似 HTTP/1.1 keepalive 或 HTTP/2 多路复用那样的连接复用机制。
为什么 Stream 模块无法做 TCP 连接复用？
连接复用的前提是代理能识别并区分“多个逻辑请求”，而 Stream 模块只负责建立后端连接、转发原始数据流，并在连接关闭时被动释放。它不会：
- 解析数据包边界（例如无法识别 Redis 的
*3\r\n$3\r\nSET\r\n...或 MySQL 的报文长度字段） - 缓存或重用已建立的上游连接供不同客户端共用（默认是 per-client-per-upstream 连接）
- 主动管理连接生命周期（如空闲超时复用、健康检查后保持连接）
但可以实现“上游连接复用”（upstream connection reuse）
虽然不能让一个客户端复用连接发多次请求，Nginx Stream 支持对同一客户端后续新建连接，复用已缓存的上游连接（前提是后端服务支持长连接且 Nginx 配置得当）。关键配置如下：
-
启用 upstream 连接池：使用
keepalive指令指定每个 worker 进程最多缓存多少个空闲上游连接 -
设置合理的超时：配合
keepalive_timeout（默认 60s）和proxy_timeout类指令，避免连接过早断开 -
确保后端支持长连接：例如 Redis 默认 keepalive 开启；MySQL 需要服务端配置
wait_timeout> Nginx 超时值
示例配置：
upstream backend {
server 192.168.1.10:6379;
keepalive 32; # 每个 worker 缓存最多 32 个空闲连接
}
<p>server {
listen 6379;
proxy_pass backend;
proxy_timeout 10s;
proxy_responses 1; # 可选：限制单次连接最多转发几个响应（仅部分协议适用）
}</p>
真正需要“客户端连接复用”怎么办？
如果业务要求一个 TCP 连接承载多个请求（比如自定义协议、Redis pipeline、MQTT 等），需依赖客户端和服务端自身支持长连接 + 协议帧解析，Nginx Stream 只需不干扰即可：
- 确保
tcp_nodelay on（默认开启），避免 Nagle 算法引入延迟 - 禁用
proxy_buffering off（Stream 模块默认不缓冲，无需额外关） - 若需连接级限速或控制，并发数限制，可用
limit_conn和limit_rate
此时“复用”实际发生在客户端与 Nginx 之间、以及 Nginx 与后端之间两段独立连接上，Nginx 不感知请求语义，只是透明中继。
替代方案：用 HTTP 模块 + Upgrade 实现更可控的复用
若协议可适配 WebSocket 或自定义 upgrade 流程（如 gRPC-Web），可切换到 HTTP 模块，利用 Upgrade 和 Connection: upgrade 升级为长连接，并借助 keepalive_requests、keepalive_timeout 精细控制复用行为。但这已超出 Stream 模块范畴。
