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 解析、重写或会话保持逻辑

关键行为特点

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 不终止 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 跳板等对协议完整性要求高、又需要统一入口和基础负载能力的场景。