必须开启 proxy_ssl_server_name on，否则 Nginx 与后端 HTTPS 服务 TLS 握手时缺失 SNI，导致证书选择错误、403 或连接失败；该配置仅在 proxy_pass 指向 HTTPS 地址时必需，并需配合 proxy_ssl_protocols 等指令使用。
启用 proxy_ssl_server_name on 是解决 Nginx 反向代理 HTTPS 后端时 TLS 握手失败的关键一步，尤其在后端使用 SNI 多证书部署的场景下——它让 Nginx 在发起 SSL 连接时主动带上客户端请求的域名（即 SNI 扩展），避免上游因无法识别目标主机而拒绝握手或返回错误证书。
为什么必须开 proxy_ssl_server_name？
Nginx 默认以 IP 地址或 proxy_pass 中的字面主机名建立 TLS 连接，不发送 SNI 字段。而现代 HTTPS 服务（尤其是 CDN 回源、多域名共用 IP 的负载均衡器）依赖 SNI 来选择对应证书。若缺失该字段，上游可能：
- 直接中断 TLS 握手，报错如
SSL_do_handshake() failed或tlsv1 alert internal error - 返回默认/通配符证书，导致证书域名不匹配，触发客户端校验失败
- 在严格模式下直接关闭连接，表现为 502 Bad Gateway
proxy_ssl_name 要怎么配才有效？
proxy_ssl_name 必须配合 proxy_ssl_server_name on 使用，且推荐动态设置，而非写死：
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 用
$host：最常用，已标准化，不含端口，值来自请求头 Host 字段（经 Nginx 解析后） - 用
$http_x_forwarded_host：当 CDN 改写了原始 Host（如 Cloudflare 默认行为），需让 CDN 透传原始域名到该自定义头，再在此处引用 - 避免纯字符串如
"example.com"：仅适用于固定单域名回源；多域名场景下硬编码会导致其他请求 SNI 错误
常见配置陷阱与验证方法
即使开了 SNI，仍可能因细节出错而失效：
- 上游未开启 SNI 支持（如旧版 Nginx、某些四层 LB），需确认其 TLS 层支持 Server Name Indication
- CDN 回源协议不是 HTTPS：若 CDN 实际走 HTTP 回源，
proxy_ssl_*指令完全不生效 - 证书绑定域名不符：可用
openssl s_client -connect host:443 -servername host验证上游是否对指定 SNI 返回了正确证书 - 日志调试：在上游 Nginx 的 error_log 中加
debug级别，搜索SSL handshake日志，确认收到的 SNI 值是否与预期一致
典型正确配置片段
以下为生产环境常用写法，兼顾安全与兼容性：
location /api/ {
proxy_pass https://10.0.0.100;
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_verify off; # 若上游证书非权威 CA 签发，临时关闭校验
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
