proxy_ssl_name 是 Nginx 中用于显式指定 TLS 握手时 SNI 域名的指令，需配合 proxy_ssl_server_name on 使用，仅影响 SNI 字段而不改变 Host 头，适用于 HTTPS 后端多虚拟主机场景。
proxy_ssl_name 是 Nginx 反向代理中用于显式指定 TLS 握手阶段 SNI（Server Name Indication）字段值的指令，主要在代理后端是 HTTPS 服务（如上游 API、CDN 或另一个 HTTPS 站点）时使用。它不决定路由或 Host 头，只影响客户端（即 Nginx）向后端发起 TLS 连接时发送的 SNI 域名。
为什么需要配置 proxy_ssl_name
当 Nginx 作为反向代理访问 HTTPS 后端（例如 https://api.example.com），若后端依赖 SNI 区分虚拟主机（比如同一 IP 托管多个 HTTPS 站点），而 Nginx 默认用 proxy_pass 中的域名或 IP 作为 SNI，可能不匹配实际目标主机名，导致证书校验失败或后端拒绝连接。此时需显式设置 proxy_ssl_name 来对齐预期的 SNI 值。
基本配置写法
该指令必须与 proxy_ssl_server_name on 配合使用（启用 SNI 发送），且仅在 location 或 server 块中生效：
- 开启 SNI：添加
proxy_ssl_server_name on; - 指定 SNI 域名：添加
proxy_ssl_name "api.example.com";（注意：必须加引号，支持变量如$host或$upstream_host） - 确保
proxy_pass指向 HTTPS 地址（如https://backend:443），否则该配置无效
常见典型场景与写法示例
场景1：固定上游域名
后端始终是 https://svc.internal.company，但其证书 CN/SAN 为 svc.internal.company，而 DNS 解析出的 IP 上托管了多个服务：
location /api/ {
proxy_pass https://10.1.2.3:443;
proxy_ssl_server_name on;
proxy_ssl_name "svc.internal.company";
}
场景2：动态继承请求 Host
希望 SNI 与客户端请求的 Host 头一致（适用于多租户或泛域名代理）：
proxy_ssl_name "$host";- 需确保
$host是可信值（避免恶意 Host 头注入），生产环境建议配合valid_referers或白名单校验
场景3：配合 upstream 使用变量
当 upstream 定义了多个后端并用变量选择时：
upstream api_cluster {
server api-v1.example.com:443;
server api-v2.example.com:443;
}
location / {
set $upstream_name "api-v1.example.com";
proxy_pass https://api_cluster;
proxy_ssl_server_name on;
proxy_ssl_name $upstream_name;
}
注意事项与排错要点
-
proxy_ssl_name 不影响 HTTP Host 请求头：Host 头由
proxy_set_header Host ...控制，二者独立 - 证书验证仍依赖
proxy_ssl_trusted_certificate和proxy_ssl_verify on；仅设proxy_ssl_name不跳过证书校验 - 若后端返回 “SSL certificate error” 或 Nginx 日志出现
SSL_do_handshake() failed，先确认 SNI 是否匹配证书 SAN 列表 - Nginx 版本需 ≥ 1.7.0（SNI 支持）；≥ 1.11.5 才支持变量形式的
proxy_ssl_name
