Nginx TCP代理高可用架构依赖stream模块实现四层接入层，需确认编译含--with-stream且主配置显式加载模块；通过upstream配置被动健康检查、backup备用节点及least_conn等调度策略；结合so_keepalive、proxy_timeout等参数优化连接控制，并建议补充主动健康检查或外部方案提升可靠性。
Nginx 的 TCP 代理高可用架构，核心在于用 stream 模块构建稳定、可自动故障转移的四层接入层，不依赖应用层协议解析，靠连接控制、健康感知与合理调度协同实现。关键不是堆功能，而是把几个基础点配对、配准。
确认 stream 模块已启用并正确加载
没这个模块，其他都无从谈起。必须验证两点：
- 编译时含
--with-stream：运行nginx -V 2>&1 | grep with-stream，有输出才说明支持 - 主配置中显式加载：在
nginx.conf开头添加load_module modules/ngx_stream_core_module.so; -
stream { ... }块必须与http { ... }同级，不能嵌套在 http 内
用 upstream 实现节点管理与被动健康检查
upstream 是调度中枢，也是故障隔离的基础：
- 每个 server 行可设
max_fails=3 fail_timeout=30s：连续 3 次连接失败后，30 秒内不再转发请求 - 加
backup标记备用节点：仅当所有主节点不可用时才启用，适合灾备场景 - 长连接类服务（如 MySQL、Redis）优先选
least_conn策略，避免单节点积压 - 需会话粘性时，用
hash $remote_addr，ip_hash在 stream 模块中不支持
监听端口级连接控制优化
每个 server 块对应一个代理服务，连接行为需按业务调优：
-
so_keepalive on写在listen指令后：启用 TCP keepalive，防 NAT 或防火墙中途断连 -
proxy_timeout 3600s：MySQL 类长连接建议设为 1 小时；Redis PING 类短交互可设为 30s -
proxy_responses 1：适用于单请求单响应协议（如 MySQL handshake），收到首个响应即认为连接有效 -
proxy_buffer_size 128k：对 binlog 流、大包推送等场景，避免默认 8k 缓冲成为瓶颈
补充主动健康检查（推荐但非必需）
原生 stream 模块只做端口连通性探测，无法判断服务真实状态：
- 基础配置：
health_check interval=3s timeout=1s fails=3 passes=2;（放在 upstream 内） - 该检查仅验证三次握手成功，不能识别 Redis OOM、MySQL 只读等深层异常
- 生产环境建议搭配外部方案：Consul Health Check、自定义脚本 + nginx-stream-upsync-module，或由后端暴露
/health端点供轮询
