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 连接，一个连接生命周期可能持续数分钟甚至数小时。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 就摘除节点，恢复后自动回归。
- 机制简单、无侵入，不增加后端负担
- 对 MySQL、PostgreSQL、Redis 等无健康接口的服务尤其友好
- 故障识别快（秒级），恢复自动，无需人工干预
