Nginx反向代理到SaaS平台时，需启用SNI并动态设置proxy_ssl_name $host（或$http_x_forwarded_host），配合proxy_ssl_server_name on，确保TLS握手发送正确域名；同时透传X-Forwarded-Host头，并验证OpenSSL版本≥1.0.2h且支持tlsext。
要让 Nginx 在反向代理到 SaaS 平台（如多租户托管服务、API 网关或云厂商提供的 HTTPS 后端）时正确匹配证书，核心不是“开启 proxy_ssl_server_name”，而是让它把用户真实请求的域名，准确传给上游——这需要开启 SNI 并动态设置 SNI 字段内容。
必须同时启用 SNI 并指定动态 SNI 值
proxy_ssl_server_name on 只是打开 TLS 握手发送 SNI 扩展的能力，它本身不决定发什么。真正起作用的是 proxy_ssl_name：
- 在对应 location 块中添加 proxy_ssl_server_name on;
- 紧接着配置 proxy_ssl_name $host;（推荐）或 proxy_ssl_name $http_host;
- 避免写死，例如
proxy_ssl_name "api.saas.com";，除非所有流量都指向唯一域名 - 该配置仅对
proxy_pass https://...生效，HTTP 回源时完全忽略
应对 SaaS 平台常见的 Host 头覆盖问题
很多 SaaS 平台（如 Stripe、Shopify、Auth0 或私有化部署的多租户网关）要求回源请求的 Host 头与业务域名严格一致，而 CDN 或中间代理常会改写 Host：
- 检查是否启用了 CDN 的“透传原始 Host”功能，通常表现为传递
X-Forwarded-Host头 - Nginx 中改用 proxy_ssl_name $http_x_forwarded_host;
- 顺手加上 proxy_set_header X-Forwarded-Host $host;，方便 SaaS 后端做租户路由
- 若 SaaS 平台明确要求 Host 头为特定格式（如带端口或全小写），可配合 map 指令标准化
验证 SNI 是否真正按预期发出
配置写对 ≠ 实际生效。需从上游视角确认 TLS 握手时收到的 SNI 值：
- 在 SaaS 平台侧（或你可控的测试后端 Nginx）开启 debug 日志：
error_log /var/log/nginx/error.log debug; - 发起一次请求后，搜索日志中类似
client sent server name "app.example.com"的记录 - 用 OpenSSL 手动模拟：运行
openssl s_client -connect your-saas-backend:443 -servername app.example.com，观察返回证书的 SAN 是否包含该域名 - 注意：若上游返回默认证书或报
SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca，大概率是 SNI 未传或传错
确保底层支持到位
即使配置无误，环境缺失关键能力也会失败：
- 运行
nginx -V | grep OpenSSL，确认 OpenSSL 版本 ≥ 1.0.2h，且编译时启用了enable-tlsext - SaaS 平台后端必须支持 SNI，老版本 Nginx（
- 若平台使用私有 CA 签发证书，还需配
proxy_ssl_trusted_certificate和proxy_ssl_verify on，否则证书校验失败
