如何通过配置proxy_ssl_server_name解决代理服务器在证书云存储中SNI匹配问题？

本文共计755个文字，预计阅读时间需要4分钟。

要修改Nginx配置以正确代理到多个证书，以下是一个简化的步骤：

必须同时启用 SNI 并指定动态域名

proxy_ssl_server_name on 只是开关，它本身不决定发什么值。云存储通常一个 IP 对应成百上千个域名（如 bucket-a.example.com、bucket-b.example.com），每个域名配独立证书。Nginx 默认用 proxy_pass https://10.0.0.100 中的 IP 或写死域名当 SNI，这在云场景下完全不可用。

• 在 location 块中添加：proxy_ssl_server_name on;
• 紧接着配置：proxy_ssl_name $host;（推荐）或 proxy_ssl_name $http_host;
• 确保 proxy_pass 指向 HTTPS 地址，且协议明确，例如：proxy_pass https://storage-backend; 或 proxy_pass https://10.0.0.100;

应对 CDN 或 API 网关透传导致的 Host 失真

若请求先经过 CDN（如 Cloudflare、阿里云全站加速）、API 网关或 WAF，它们常会重写 Host 头为自身配置的源站名（如 origin.example.com），导致 $host 不再是用户原始域名，SNI 错配。

• 在 CDN 控制台开启“透传原始 Host”功能，通常表现为传递 X-Forwarded-Host 或 X-Real-Host 头
• Nginx 中改用：proxy_ssl_name $http_x_forwarded_host;
• 同时补上：proxy_set_header X-Forwarded-Host $host;，方便云存储后端做租户路由或日志审计

upstream 场景下不能依赖变量，需显式写死 SNI 值

当使用 upstream 块定义云存储节点（如负载多个网关实例），Nginx 在 SSL 握手阶段无法解析变量，$host 会报错或被忽略。

• upstream 定义示例：upstream s3_gateway { server gateway-01.internal:443; server gateway-02.internal:443; }
• 在 location 中必须加：proxy_ssl_name "bucket-a.example.com";（带双引号，字符串字面量）
• 该值要与云存储后端证书的 SAN（Subject Alternative Name）完全一致，大小写敏感；泛域名证书（*.storage.example.com）则填具体子域（my-bucket.storage.example.com）

验证 SNI 是否真正发出

配置写对 ≠ 实际生效。需确认 TLS 握手时 Client Hello 中的 SNI 字段确实是目标域名：

• 在云存储后端（如另一台 Nginx 或 Ceph RGW）开启 debug 日志：error_log /var/log/nginx/error.log debug;
• 触发一次请求后搜索日志：client sent server name "bucket-a.example.com"
• 或在 Nginx 本机用 OpenSSL 手动测试：openssl s_client -connect 10.0.0.100:443 -servername bucket-a.example.com，观察返回证书是否匹配
• 注意：若云存储回源走的是 HTTP 协议，proxy_ssl_* 系列指令完全不生效，务必先确认上游是 HTTPS