Nginx 不能代理数据库流量，因其不支持数据库协议解析、连接池及状态管理；应使用 HAProxy、PgBouncer 等专用工具，Nginx 仅适合代理 API 层、缓存、限流以间接降低数据库压力。
Nginx 本身不直接连接或代理数据库（如 MySQL、PostgreSQL），它不是数据库代理层，也不具备解析 SQL 或维护数据库连接池的能力。所谓“Nginx 利用异步非阻塞特性优化数据库反向代理”是一个常见误解——Nginx 无法替代 MySQL Router、PgBouncer、HAProxy 或专用数据库中间件来实现数据库连接的负载均衡或协议转发。
为什么 Nginx 不能真正代理数据库流量
Nginx 的反向代理能力基于应用层（HTTP/HTTPS）或传输层（TCP/UDP，需 stream 模块启用），但数据库协议（如 MySQL 的 binary protocol、PostgreSQL 的 frontend/backend 协议）具有状态强依赖、连接生命周期长、认证交互复杂等特点：
- MySQL 握手过程包含初始握手包、SSL 请求、认证响应、能力协商等多轮交互，Nginx stream 模块仅做字节流转发，不理解语义，无法处理连接复用、会话保持或连接中断重试
- PostgreSQL 协议要求客户端先发送 StartupMessage，服务端返回 Authentication response，后续才进入查询阶段；Nginx 不解析这些消息，无法做健康检查或协议感知路由
- 数据库连接常带 session 级上下文（如临时表、变量设置、事务状态），简单 TCP 透传易导致状态错乱或连接泄漏
可行的替代方案与合理定位
若目标是提升数据库访问性能、高可用或连接管理效率，应选择符合协议特性的工具，并让 Nginx 承担其擅长的角色：
- 用 HAProxy 或 Envoy 做数据库 TCP 层负载均衡：支持 MySQL/PostgreSQL 协议健康检查（如 send/expect 自定义探针）、连接限制、慢连接剔除，比 Nginx stream 更健壮
- 用 PgBouncer（PostgreSQL）或 MySQL Router（MySQL）做连接池与路由：解决应用频繁建连开销，支持事务级/会话级池化，Nginx 不提供此类能力
- Nginx 可代理 API 层，间接优化数据库压力：将业务逻辑封装为 HTTP 接口（如 FastAPI/Node.js），Nginx 对其做缓存、限流、SSL 终结、灰度发布，减少无效请求穿透到后端服务，从而降低数据库调用频次
若坚持用 Nginx stream 做 TCP 透传，需注意的关键点
仅适用于简单场景（如测试环境、主从只读分离且无认证变更），必须手动规避风险：
- 启用
stream模块，配置tcp_nodelay on和合理的timeout（如proxy_timeout 1h），避免小包延迟和连接僵死 - 使用
health_check（Nginx Plus）或配合外部脚本 +status指令模拟探测，不可依赖默认 TCP connect 成功即认为 DB 可用 - 禁止在 stream 块中使用 rewrite、set 等 HTTP 模块指令；不支持 header 修改、JWT 验证等应用层控制
- 日志仅能记录连接建立/关闭（
log_format log_stream ...），无法记录 SQL 或响应时长，排障困难
真正发挥 Nginx 异步非阻塞优势的方向
Nginx 的事件驱动模型最适配高并发、低计算开销的任务：
- 静态资源服务（CSS/JS/图片）零拷贝响应，释放后端数据库连接
- 对 API 接口启用
proxy_cache，缓存 GET 类查询结果（如商品详情、配置项），命中时完全绕过后端和数据库 - 用
limit_req控制单 IP 接口调用频率，防止恶意刷量拖垮数据库 - 结合 OpenResty，在 Nginx 进程内用 Lua 缓存热点数据（如 Redis 查询结果），减少穿透查询
