必须显式配置 proxy_ssl_on、proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name 和 proxy_ssl_server_name 五项指令,缺一不可且须同处 location 或 upstream 块内,否则 tls 握手失败或证书校验静默失效。

Nginx 默认用明文连接后端,哪怕 proxy_pass https:// 也只是改了协议地址,不会自动启用 TLS 握手或证书校验。真正开启安全的后端加密通信,必须显式配置 proxy_ssl_* 系列指令——它们不是可选增强,而是强制开关。
必须启用的核心四要素
这四项需同时出现在同一个 location 或 upstream 块内,缺一不可:
- proxy_ssl on; —— 全局开关,不加则所有 proxy_ssl_* 指令无效
- proxy_ssl_verify on; —— 启用证书有效性校验(生产环境必须开启)
- proxy_ssl_trusted_certificate /path/to/ca.pem; —— 指定可信根证书路径(PEM 格式),用于验证后端证书链;自签名或私有 CA 必须提供
- proxy_ssl_name "backend.example.com"; —— 显式指定证书校验和 SNI 使用的主机名,必须与后端证书中的 SAN 或 CN 完全一致
务必配合 SNI 支持
多数现代 HTTPS 后端(如多租户网关、K8s Ingress、Next.js SSR 接口)依赖 SNI 区分虚拟主机。Nginx 默认不发送 SNI,会导致证书选择错误、403 或握手失败:
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 添加 proxy_ssl_server_name on; 强制发送 SNI 扩展
- 若
proxy_pass写的是 IP 或别名(如https://10.0.1.5:8443),proxy_ssl_name就更关键——它告诉 Nginx “该向谁要证书”,否则校验直接失败
连接复用与稳定性保障
避免每次请求都重做 TLS 握手(耗时 80–120ms,CPU 翻倍),需启用会话复用并确保底层连接池就绪:
-
proxy_ssl_session_reuse on; —— 必须放在
upstream块内才生效 - 配套
keepalive 32;(每个 worker 缓存空闲连接数) - 加上
proxy_http_version 1.1;和proxy_set_header Connection "";,防止后端主动断连清空连接池 - 后端多实例共用 IP 时,
proxy_ssl_server_name on仍是前提,否则 SNI 错误导致复用失效
调试常见失败点
出现 SSL_do_handshake() failed 或 certificate verify failed 时,按顺序检查:
- 确认
proxy_ssl on;没被嵌套的if或低优先级location覆盖 - 用
openssl s_client -connect 10.0.1.5:8443 -servername backend.example.com直连测试后端 TLS 是否正常 - 检查
proxy_ssl_trusted_certificate文件是否为绝对路径、权限为 Nginx worker 可读(如chmod 644) - 临时开启
error_log /var/log/nginx/error.log debug;查看 SSL 握手细节(仅调试用)










