Nginx Stream模块工作在OSI四层，对TCP字节流透明转发，不解析应用层协议；按连接而非请求处理，依赖内核socket接口高效转发；健康检查被动感知，负载策略仅支持连接数或IP哈希。
核心原理是：在传输层做原始字节流的透明转发，不解析应用层协议，只管理 TCP 连接生命周期。
工作在 OSI 四层，不碰协议内容
Stream 模块运行在传输层，拿到的是完整的 TCP 数据包，不做任何协议解析（比如不识别 MySQL 的握手包、Redis 的 RESP 命令或 SSH 的密钥交换）。它只负责把客户端发来的字节原样推给后端，再把后端回的字节原样传回客户端——整个过程像一根“管道”，中间零修改。
连接驱动，非请求驱动
HTTP 代理按 request/response 处理，而 Stream 是按连接处理：一个 TCP 连接建立后，Nginx 就为其维持双向数据通道，直到任意一方关闭或超时。没有 header、状态码、重试机制这些 HTTP 概念，只有 socket 级别的读写和超时控制。
依赖内核 socket 接口，轻量高效
所有数据转发都走系统调用（如 read/write/sendfile），底层由 epoll（Linux）或 kqueue（BSD）驱动事件循环。性能瓶颈主要在 worker_connections 设置、缓冲区大小和网络延迟，而非 Nginx 自身逻辑开销。
健康检查靠被动感知，不主动探测
Stream 模块默认不主动 ping 后端，而是通过连接建立失败（connection refused）、写入失败（broken pipe）或 proxy_timeout 触发的超时来标记节点不可用。配合 upstream 中的 max_fails 和 fail_timeout，实现简单但有效的故障摘除。
负载策略基于连接数或 IP 哈希
支持 least_conn（选当前连接最少的后端）、hash $remote_addr（相同客户端 IP 总打到同一台），但不支持基于响应时间或权重动态调整——因为没响应体可分析，也没请求粒度可统计。
