Nginx 本身不能代理数据库原生协议（如 MySQL 二进制协议），仅能通过 stream 模块做四层 TCP 透传转发，或通过 HTTP API 封装后由反向代理负载均衡；直接代理数据库连接超出其设计能力，应选用 HAProxy、PgPool-II 等专用中间件。
✅ 方式一：HTTP API 封装 + Nginx 反向代理（推荐）
这是安全、可控、符合云原生实践的方式。数据库不直接暴露给外部，所有读写请求经由业务服务（如 Node.js/Python/Java 服务）封装为 HTTP 接口，Nginx 对这些服务做负载均衡。
- 后端服务负责连接池管理、SQL 安全校验、读写分离、分库分表逻辑
- Nginx 配置示例（负载均衡多个 API 实例）：
upstream db_api_servers {
least_conn;
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=30s;
}
server {
listen 80;
location /api/db/ {
proxy_pass http://db_api_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
客户端调用 http://your-domain.com/api/db/query，实际由后端服务执行 SQL 并返回 JSON。
⚠️ 方式二：Nginx Stream 模块 TCP 透传（谨慎使用）
Nginx 的 stream 模块可做四层代理，转发 TCP 流量（如 MySQL 3306 端口）。但它不解析协议、不改写数据包、不支持连接复用或健康检查（需配合 keepalive 和自定义脚本），且存在连接泄漏、事务中断、认证失败等风险。
- 仅适合简单主从切换或同构集群（如多个只读 MySQL 从库）
- 必须关闭 MySQL 客户端的 auto-reconnect，避免因后端节点宕机导致长连接卡死
- 配置示例（nginx.conf 中新增 stream 块）：
stream {
upstream mysql_backend {
least_conn;
server 192.168.1.20:3306 max_fails=1 fail_timeout=10s;
server 192.168.1.21:3306 max_fails=1 fail_timeout=10s;
}
server {
listen 3307;
proxy_pass mysql_backend;
proxy_timeout 1s;
proxy_responses 1;
}
}
客户端连接 127.0.0.1:3307，流量被轮询转发到后端 MySQL 实例。注意：MySQL 用户名密码、SSL、权限等仍由后端数据库控制，Nginx 不参与认证。
❌ 不可行方案提醒
直接让 Nginx “代理数据库连接”并期望它理解 SQL、做分片、处理事务——这超出了其设计边界。类似需求应交由专业中间件完成：
- MySQL 分片：ShardingSphere Proxy、MyCat、Vitess
- PostgreSQL 集群：PgPool-II、Patroni + HAProxy、Citus
- 通用协议代理：HAProxy（比 Nginx stream 更适合数据库 TCP 转发）、Envoy（支持更丰富的 L4/L7 过滤）
强行用 Nginx 替代这些组件，会牺牲可观测性、连接治理能力与运维弹性。
不复杂但容易忽略：数据库访问的本质是状态连接与事务语义，而 Nginx 的强项是无状态请求调度。选对工具层，比硬套方案更重要。
