Nginx反向代理需正确透传SNI才能避免上游证书错配，核心是启用proxy_ssl_server_name on并动态设置proxy_ssl_name $host（或$http_x_forwarded_host），配合debug日志与openssl验证确保生效。

Nginx 默认不发送 SNI 字段，当反向代理到一个 IP 托管多个 HTTPS 域名（如多租户网关、CDN 回源目标、SaaS 后端或对象存储）时，上游无法识别客户端真实意图，会返回默认证书或直接中断 TLS 握手，导致 502、403 或证书校验失败。解决问题的核心不是只开 `proxy_ssl_server_name on`，而是让它把用户请求的原始域名作为 SNI 值发出去。

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

仅开启 `proxy_ssl_server_name on` 不足以生效，它只是“允许发 SNI”，真正起作用的是 `proxy_ssl_name` 的值：

• 在对应 location 或 upstream 块中添加：proxy_ssl_server_name on;
• 紧接着设置：proxy_ssl_name $host;（推荐）——$host 已标准化为小写、不含端口，比 $http_host 更安全
• 避免写死静态值，例如 proxy_ssl_name "api.example.com";，除非所有请求都指向唯一后端域名

应对 CDN 或网关覆盖 Host 头的情况

Cloudflare、阿里云全站加速等常将 Host 头重写为源站域名（如 origin.example.com），导致 $host 失真，SNI 错配：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 在 CDN 控制台开启“透传原始 Host”功能，通常体现为自动携带 X-Forwarded-Host 请求头
• Nginx 中改用：proxy_ssl_name $http_x_forwarded_host;
• 顺手加上：proxy_set_header X-Forwarded-Host $host;，方便后端日志溯源和业务识别

upstream 场景下不能省略 proxy_ssl_name

使用 upstream 做负载均衡时，Nginx 解析域名得到 IP 后仍需明确告知 SNI 值，否则依然错配：

• upstream api_backend { server api.example.com:443; }
• 在 location 中必须写：proxy_ssl_name "api.example.com";（注意加引号，值为字符串）
• 配套保留：proxy_ssl_server_name on; 和 proxy_set_header Host "api.example.com";

验证 SNI 是否真正发出

配置写对 ≠ 运行有效。必须确认 TLS 握手阶段实际发出的 SNI 值就是用户访问的域名：

• 在上游服务器（如另一台 Nginx）开启 debug 日志：error_log /var/log/nginx/error.log debug;，搜索 client sent server name 字样
• 用 OpenSSL 手动模拟：openssl s_client -connect 10.0.0.100:443 -servername your-domain.com，观察返回证书的 CN 或 SAN 是否匹配
• 检查 Nginx 编译信息：nginx -V | grep OpenSSL，确保加载的是 OpenSSL ≥1.0.2h 且启用了 TLS extensions