nginx默认不编译stream模块，需显式启用——ubuntu装nginx-full、centos用nginx-mod-stream或源码加--with-stream；该模块与http同级且端口不能重叠，验证命令为nginx -v 2>&1 | grep -o with-stream。
Nginx 本身不支持对 MySQL（TCP 层）做原生四层负载均衡；必须用 stream 模块，且不能和 http 模块共用同一监听端口，否则会冲突。
为什么 nginx -v 看不到 stream 模块？
大多数系统包管理器安装的 nginx（如 Ubuntu 的 apt、CentOS 的 dnf）默认不编译 stream 模块。它属于可选模块，需显式启用：
- Debian/Ubuntu：安装
nginx-full而非nginx-light - CentOS/RHEL：需从源码编译，或使用 EPEL 提供的
nginx-mod-stream包（RHEL 8+） - 验证方式：
nginx -V 2>&1 | grep -o with-stream—— 若无输出，说明未启用
stream 块必须独立于 http 块，且监听端口不能重叠
stream 是全局层级指令，不能写在 http 块内，也不能和 http { server { listen 3306; ... } } 共存。MySQL 默认端口 3306 只能被 stream 或 http 中的一个占用。
典型正确结构：
events {
worker_connections 1024;
}
<p>stream {
upstream mysql_backend {
server 192.168.1.10:3306 max_fails=3 fail_timeout=30s;
server 192.168.1.11:3306 max_fails=3 fail_timeout=30s;</p><h1>注意：不支持 proxy_set_header（无 HTTP 头），但支持 proxy_protocol</h1><pre class="brush:php;toolbar:false;">}
server {
listen 3307; // 必须换端口！比如对外暴露 3307
proxy_pass mysql_backend;
proxy_timeout 1h;
proxy_responses 1;
}}
客户端连接时，要连 nginx_ip:3307，而非直连后端 MySQL 端口。
MySQL 客户端连接失败的三个常见原因
即使配置语法正确，仍可能连不上，重点排查：
-
bind_address在 MySQL 配置中设为127.0.0.1：后端 MySQL 必须监听0.0.0.0或内网 IP，否则 Nginx 无法建立 TCP 连接 - 防火墙拦截：检查 Nginx 服务器的
3307入站 + 后端 MySQL 服务器的3306出站（或双向）规则 - MySQL 用户权限未授权给 Nginx 所在 IP：
CREATE USER 'app'@'192.168.1.%' IDENTIFIED BY 'pwd';，不能只给'app'@'localhost'
真正容易被忽略的是：stream 模块下没有健康检查回调机制，max_fails 和 fail_timeout 仅基于 connect/read timeout 判定，若 MySQL 进程僵死但端口仍通（如卡在 auth 阶段），Nginx 无法感知，请求会卡住或返回 Lost connection to MySQL server。生产环境建议搭配 tcp_check 脚本或改用 ProxySQL。
