Nginx Stream模块以透明代理方式在传输层转发TCP原始字节流，不解析应用层协议，支持负载均衡、被动健康检查，适用于MySQL、Redis等需协议完整性的场景。
Nginx 的 Stream 模块处理 TCP 流量时，不解析应用层协议，只在传输层做原始字节流转发，整个过程轻量、高效、无状态。
Stream 模块的 TCP 代理工作流程
- 客户端发起 TCP 连接请求（如
telnet 192.168.1.100 3307），Nginx 在监听端口（如listen 3307）上接受该连接 - Nginx 根据
proxy_pass指向的upstream组，按配置策略（轮询、least_conn、hash 等）选择一个后端服务器 - Nginx 与选定后端建立新的 TCP 连接，并在客户端连接与后端连接之间建立双向数据通道
- 所有原始 TCP 数据包直接透传：客户端发来的字节流 → Nginx 缓冲 → 后端；后端响应字节流 → Nginx 缓冲 → 客户端
- 连接生命周期由超时参数控制（如
proxy_timeout、proxy_connect_timeout），不涉及 HTTP 的 header 解析、重写或会话保持逻辑
关键行为特点
- 不终止 TCP 连接，也不重建连接语义，属于“透明代理”模式
- 不感知 payload 内容：MySQL 协议、Redis RESP、SSH 握手、自定义二进制协议均可原样通过
- 每个客户端连接独占一个 worker 进程中的连接上下文，不共享连接池（区别于 HTTP 的 keepalive 复用）
- 支持被动健康检查（基于连接失败次数 +
max_fails/fail_timeout），但不支持主动探测（需配合第三方模块或外部监控）
底层依赖与限制
- 依赖内核 socket 接口，所有读写均走系统调用，性能受
worker_connections和epoll（Linux）效率影响 - 不支持
rewrite、return、if、access_log（原生）、limit_conn（需stream_limit_conn_module扩展）等 HTTP 特有指令 -
upstream中不能使用域名动态解析（除非启用resolve指令并配置 resolver，且仅限于部分版本）
这种设计让 Stream 模块特别适合数据库、消息中间件、SSH 跳板等对协议完整性要求高、又需要统一入口和基础负载能力的场景。
