必须同时启用 proxy_ssl_server_name on 并配置 proxy_ssl_name $host，否则 https 后端因缺失或错误 sni 无法选择正确证书，导致 tls 握手失败；还需 proxy_set_header host $host 保持请求头一致。
单纯开启 proxy_ssl_server_name on 不能解决 SNI 匹配问题，真正起作用的是它与 proxy_ssl_name 的配合——前者启用发送 SNI 的能力，后者决定发什么值。
必须同时启用并动态设置 SNI 值
Nginx 默认用 proxy_pass 后写的地址（如 https://10.0.0.100）作为 SNI 字段内容。这在后端只服务一个域名时可行，但遇到多证书场景（比如一个 IP 对应 shop-a.com、shop-b.net 两个独立站点），就会固定错配。
- 添加
proxy_ssl_server_name on;到location块中（不支持写在upstream内） - 紧接着配置
proxy_ssl_name $host;，让 SNI 值随客户端请求的 Host 头实时变化 - 避免写死字符串，例如
proxy_ssl_name "api.example.com";，除非所有请求都指向同一域名
应对 CDN 回源时 Host 被覆盖的情况
Cloudflare、阿里云全站加速等 CDN 回源时通常会重写 Host 头为源站配置名，导致 $host 变成 CDN 设定的源站域名，而非用户原始请求域名（如用户访问的是 shop-a.com，但 Nginx 收到的 Host 是 origin.example.com）。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 在 CDN 控制台开启“透传原始 Host”功能，一般体现为传递
X-Forwarded-Host请求头 - Nginx 中改用
proxy_ssl_name $http_x_forwarded_host; - 同时建议加一句
proxy_set_header X-Forwarded-Host $host;，方便下游识别真实请求来源
验证 SNI 是否按预期发出
配置写对不等于生效，必须确认 TLS 握手阶段实际发出的 SNI 值是否正确。
- 在上游服务器（如另一台 Nginx 或测试 OpenSSL 服务端）开启 debug 日志：
error_log /var/log/nginx/error.log debug; - 触发一次请求后，搜索日志中
client sent server name或SSL_do_handshake相关条目，核对收到的域名是否与客户端原始请求一致 - 更直接的方式：用
openssl s_client -connect 上游IP:443 -servername your-domain.com模拟请求，观察返回的证书是否匹配该域名
常见失效原因补充
即使配置无误，仍可能因底层依赖失败：
-
proxy_ssl_server_name仅对proxy_pass https://生效，HTTP 回源时该指令被忽略 - 上游服务（如旧版 Nginx、某些负载均衡器）未启用或不支持 SNI 解析，需确认其 OpenSSL 版本 ≥ 0.9.8j 且已开启 SNI 支持
- 若使用
upstream块定义后端，proxy_ssl_server_name必须放在引用它的location中，不能只写在upstream内
