nginx stream模块实现tcp代理高可用的核心是作为可靠四层入口，稳定分发连接并自动故障转移；需先验证with-stream编译支持，配置置于顶层stream块，依赖tcp健康检查与合理超时、缓冲等参数协同后端集群。
Nginx Stream 模块做 TCP 代理高可用集群，核心不是“自己建集群”，而是把 Nginx 当作一个可靠的四层流量入口，把客户端连接稳定、自动地分发到后端真实的服务节点，并在节点异常时快速绕过。它不解析协议、不维护连接池，但能靠轻量机制实现生产级的故障转移。
确认 Stream 模块已启用
必须先验证 Nginx 支持该功能，否则配置会报 unknown directive "stream" 错误：
- 运行
nginx -V 2>&1 | grep -- '--with-stream' - 若有输出，说明编译时已开启；若无，需重编译（加
--with-stream）或换用 OpenResty / 官方 stable 包（如 Ubuntu 的nginx-full）
配置结构必须放在顶层，不能嵌套在 http 块里
Stream 是和 http 平级的模块，所有配置写在 nginx.conf 最外层：
-
stream { ... }块独立存在 -
upstream定义后端组，server在 stream 上下文中表示“监听一个 TCP 端口”，不是 HTTP 虚拟主机
定义带健康检查的 upstream 组
只靠 IP+端口存活判断不够可靠，但这是 Stream 原生唯一支持的探活方式：
-
max_fails=3 fail_timeout=30s：连续失败 3 次，30 秒内不再转发 -
health_check interval=3s fails=3 passes=2 timeout=1s：主动探测（需配合stream模块启用） - 注意：该检查仅验证 TCP 握手成功，无法识别 Redis OOM、MySQL 只读状态等业务级异常，建议搭配外部脚本或 Consul 做深度探活
设置合理的连接生命周期参数
TCP 代理性能高度依赖连接管理：
-
proxy_timeout 5s：空闲超时，避免僵死连接占满 worker -
proxy_responses 1：适用于 PING/RESP 类单应答协议，收到第一个包就关闭连接，减少资源占用 -
proxy_buffer_size 128k：对 MySQL 二进制日志、Redis 大响应等场景，适当调大缓冲区 -
so_keepalive=on：加在listen指令后（如listen 6379 so_keepalive=on），防止 NAT 设备或防火墙静默断连
负载策略与节点角色控制
Stream 支持基础调度逻辑，满足多数场景：
-
hash $remote_addr consistent：IP 一致性哈希，适合 Redis 缓存场景，保证同一客户端始终打到同一节点 -
least_conn：按当前活跃连接数分发，适合连接时长差异大的服务（如 SSH、MQTT） -
backup标记备用节点：仅当所有主节点不可用时才启用，可用于灾备切换 -
down手动下线节点：配置热更新后立即生效，无需重启
基本上就这些。关键不在功能多强大，而在于理解它只做“可靠管道”——不替代客户端连接池，也不代替后端高可用机制，而是让整个链路更稳、更易运维。
