nginx stream 代理数据库的单向/双向认证需后端mysql启用ssl,stream仅透传tls;单向由客户端验证服务端证书,双向需nginx校验客户端证书或mysql直接绑定证书认证。

配置 Nginx Stream 模块代理内网数据库时,单向认证和双向认证不是 TLS 层面的“证书验证”,而是指是否启用客户端身份校验机制。Stream 模块本身不解析 MySQL 协议内容,也不原生支持 TLS 握手中的证书交换——它只做 TCP 透传。因此,真正的单向/双向认证必须由后端数据库(如 MySQL)自身开启 SSL,并通过 Nginx 的 ssl_preread 或 proxy_ssl 相关指令配合实现。常见误区是误以为仅靠 stream { } 块里的 ssl_* 参数就能完成 mTLS,其实不然。
单向认证:让客户端验证数据库身份
这是最基础的安全增强,目标是防止中间人窃听或冒充数据库。核心是确保客户端连接时强制走加密通道,并信任服务端证书。
- 数据库端需启用 SSL:MySQL 中设置 require_secure_transport = ON,并配置 ssl_ca、ssl_cert、ssl_key
- Nginx Stream 配置中启用 SSL 透传,但不校验客户端:
stream {
upstream mysql_backend {
server 192.168.1.101:3306;
}
server {
listen 3307 ssl;
ssl_certificate /etc/nginx/ssl/db-server.crt;
ssl_certificate_key /etc/nginx/ssl/db-server.key;
proxy_pass mysql_backend;
}
}
注意:这里的证书是 Nginx 自己的 TLS 终止证书,用于对外暴露的 3307 端口;它与 MySQL 后端的证书无关,仅建立客户端到 Nginx 的加密链路。 - 客户端连接命令需指定 --ssl-mode=REQUIRED,例如:
mysql -h your-nginx-ip -P 3307 -u user -p --ssl-mode=REQUIRED
双向认证:Nginx + 数据库联合验证客户端证书
真正实现 mTLS(双向 TLS),需要两个环节协同:Nginx 在 TLS 层验证客户端证书有效性,再将合法连接透传给已启用 SSL 的 MySQL;后者可进一步校验用户证书绑定的账号权限。
- 准备三类证书:
• CA 根证书(用于签发服务端和客户端证书)
• Nginx 服务端证书(由该 CA 签发,供客户端验证)
• 客户端证书+私钥(同样由该 CA 签发,供 Nginx 验证) - Nginx Stream 配置关键项:
server {
listen 3307 ssl;
ssl_certificate /etc/nginx/ssl/db-server.crt;
ssl_certificate_key /etc/nginx/ssl/db-server.key;
ssl_client_certificate /etc/nginx/ssl/ca-bundle.crt;
ssl_verify_client on;
ssl_verify_depth 2;
proxy_pass mysql_backend;
}
其中 ssl_client_certificate 是 CA 证书链,ssl_verify_client on 强制要求并验证客户端证书。 - 客户端需携带证书连接:
mysql -h your-nginx-ip -P 3307 -u user -p \
--ssl-ca=/path/to/ca.crt \
--ssl-cert=/path/to/client.crt \
--ssl-key=/path/to/client.key \
--ssl-mode=VERIFY_IDENTITY
绕过 Nginx TLS,直接由 MySQL 处理双向认证
若希望数据库自身完成全部证书校验(更符合传统 mTLS 模式),Nginx 只做纯 TCP 代理,那就不能启用 listen ... ssl,而应关闭 TLS 终止,改用 ssl_preread 提取 SNI 或协议特征后转发——但这对 MySQL 不适用(无 SNI)。此时推荐方案是:
- Nginx 配置为纯 TCP 代理(不启用任何 ssl_* 指令)
- MySQL 启用 SSL 并配置 require_secure_transport = ON 和 ssl_ca/ssl_cert/ssl_key
- 在 MySQL 用户创建时绑定证书:
CREATE USER 'appuser'@'%' REQUIRE SUBJECT "/CN=client-app" ISSUER "/CN=MyInternalCA";
这样只有持有对应证书的客户端才能以该用户登录,Nginx 仅负责网络可达性,不参与证书判断。
补充安全加固建议
无论采用哪种模式,都应叠加以下措施提升整体防护水位:
- 限制访问 IP:在 server 块中使用 allow/deny 或结合 geo 模块控制来源
- 设置连接超时:proxy_timeout 30s; 防止僵死连接堆积
- 启用日志记录:access_log /var/log/nginx/stream-mysql.log; 方便审计异常连接
- 定期轮换证书:CA、服务端、客户端证书均应设定合理有效期,并建立更新流程











