必须开启 proxy_ssl_server_name on，否则 Nginx 与 HTTPS 后端 TLS 握手不发送 SNI，导致上游无法区分虚拟主机而返回默认证书或拒绝连接；该指令需与 proxy_pass https:// 同作用域，且必须配合 proxy_ssl_name 动态指定 SNI 值（如 $host）才能确保证书匹配和路由正确。
proxy_ssl_server_name 是 Nginx 与 HTTPS 后端建立 TLS 连接时控制是否发送 SNI（Server Name Indication）的关键开关。它默认关闭，必须显式启用才能让上游服务器正确识别目标虚拟主机，否则可能因证书不匹配或路由错误导致连接失败。
什么时候必须开启 proxy_ssl_server_name
当 Nginx 的 proxy_pass 指向一个 HTTPS 地址，且该地址所在 IP 上托管了多个域名（例如 CDN 回源、多租户 API 网关、共享 IP 的微服务集群），上游依赖 SNI 区分不同站点时，就必须开启。如果没开，TLS 握手不带域名信息，上游只能返回默认证书或直接拒绝连接。
- 典型场景包括：Nginx 代理到 CDN 的回源地址、调用云厂商提供的 HTTPS 接口、转发请求至同一 IP 的多个后端服务
- 即使 proxy_pass 写的是域名，只要没配 proxy_ssl_server_name on，SNI 字段仍是空的或无效值
- 该指令对 HTTP 后端完全无影响，只作用于 proxy_pass 以 https:// 开头的目标
基本配置写法与位置要求
该指令需放在 location 或 server 块中，与 proxy_pass 配套使用，不能在 http 块顶层直接生效（尽管语法允许，但实际不作用于具体请求）。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 必须写成 proxy_ssl_server_name on;，off 是默认值，可省略不写
- proxy_pass 必须是 https:// 协议，例如 proxy_pass https://api.example.com;
- 若 proxy_pass 使用 IP（如 https://10.1.2.3:443），则必须配合 proxy_ssl_name 才能指定有效 SNI，否则 SNI 发送的是 IP，多数上游不接受
proxy_ssl_name 与 proxy_ssl_server_name 的协作关系
proxy_ssl_server_name 只是“是否发 SNI”的开关，真正决定发什么内容的是 proxy_ssl_name。两者常一起出现，逻辑上缺一不可：
- 未设 proxy_ssl_name 时，Nginx 默认用 $proxy_host（即 proxy_pass 解析出的域名）作为 SNI 值
- 若 proxy_pass 是 IP 或别名，而上游要求特定域名（如 origin.example.com），就必须显式写 proxy_ssl_name "origin.example.com";
- 支持变量，例如 proxy_ssl_name "$host"; 可实现按客户端 Host 头动态传递 SNI，适合泛域名代理
- proxy_ssl_name 的值必须与后端证书中的 SAN 或 CN 完全一致，否则启用 proxy_ssl_verify 时会校验失败
常见配置错误与验证方法
配置看似简单，但容易因细节疏漏导致静默失败——连接建立成功但返回错误页面或证书告警。
- 忘记加引号：proxy_ssl_name example.com 是非法语法，必须写成 proxy_ssl_name "example.com";
- proxy_pass 写成 http:// 却配了 proxy_ssl_server_name —— 此时指令被忽略，无报错但无效
- 用 curl -v 或 openssl s_client -connect 测试上游连接时，观察 Client Hello 中的 Server Name 字段是否符合预期
- 查看 Nginx error log，若出现 SSL certificate verify failed 或 SSL_do_handshake() failed，大概率是 SNI 不匹配或证书校验问题
