stream模块代理tcp的核心优势是不解析协议、低延迟高吞吐，适用于mysql、redis等长连接场景；支持连接粒度负载均衡、so_keepalive保活、被动健康检查及大缓冲，但不支持七层指令。
Stream 模块代理 TCP 的核心优势，不是“功能多”，而是“不折腾协议、不拖慢连接”。它跳过应用层解析，把转发压到最轻量的路径上，天然适合数据库、Redis、游戏服这类对延迟和吞吐敏感的长连接场景。
零协议解析，降低延迟与 CPU 开销
HTTP 模块要拆包、解 header、重写、再封包；Stream 模块只做 socket 层的字节流搬运——收到数据就发给后端，后端回数据就转给客户端。没有正则匹配、没有 header 操作、不建 request 上下文。实测在千兆内网中，MySQL 查询平均延迟可比 HTTP 代理低 0.3–0.8ms，高并发时 CPU 占用下降 25% 以上。
- 适用于所有基于 TCP 的二进制或文本协议（MySQL、PostgreSQL、Redis、SSH、MQTT）
- 不支持 rewrite、add_header 等七层指令，但换来的是确定性低延迟
- 连接建立和数据流转全程在用户态完成，避免多次内核态拷贝带来的抖动
连接粒度负载均衡，贴合真实业务模型
数据库连接池通常复用 TCP 连接，一个连接生命周期可能持续数分钟甚至数小时。Stream 的 least_conn 或 hash $remote_addr（一致性哈希）策略，是按“连接”而非“请求”分发，避免了轮询导致的后端连接数严重不均。
- least_conn：适合连接生命周期长、各连接负载差异大的场景（如 MySQL 长事务）
- hash $remote_addr consistent：客户端 IP 固定绑定后端，利于连接复用与会话保持
- 每个 TCP 连接一旦选定后端，全程绑定，不跨节点切换，减少上下文切换开销
原生支持长连接保活与大流量缓冲
防火墙/NAT 设备常静默断开空闲连接，而 Stream 提供 so_keepalive 和 proxy_timeout 协同机制，确保连接“稳得住”；proxy_buffer_size 可设至 1M，应对 mysqldump、Redis RDB 同步等单次超大响应。
- so_keepalive=300s:15s:4：空闲 5 分钟启动探测，每 15 秒一次，4 次失败才断连
- proxy_timeout 必须 ≥ keepalive 总探测耗时（例如 300 + 15×4 = 360 秒），否则 Nginx 先断
- proxy_buffer_size 建议 256K–1M，注意是 per-connection 缓冲，高并发需评估内存总量
被动健康检查轻量可靠，适配数据库类服务
Stream 不依赖主动心跳探针（无需后端暴露健康接口），而是靠建连失败自动记 fail。max_fails=3 fail_timeout=30s 组合，30 秒内连续三次 connect timeout 就摘除节点，恢复后自动回归——简单但足够应对大多数数据库宕机场景。
- 不替代应用层心跳，但能快速剔除网络不通、端口未监听的节点
- backup 节点配置可实现故障自动接管，无需人工干预
- UDP 场景需搭配 match 块做协议级探测（如 DNS 响应 flag），TCP 场景仅需基础 TCP 探活
