如何通过Nginx配置proxy_ssl_server_name，轻松解决后端多虚拟主机HTTPS回源难题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计627个文字，预计阅读时间需要3分钟。
当Nginx作为反向代理，将HTTPS请求转发给上游（例如CDN、回源、多域名共用同一IP等）时，可以直接输出结果：
为什么需要 proxy_ssl_server_name
Nginx 默认在与上游建立 HTTPS 连接时，不发送 SNI 扩展。这意味着即使你配置了 proxy_pass https://example.com，Client Hello 中的 SNI 字段仍是空的或使用 IP 地址。上游若托管多个 HTTPS 域名（如 blog.example.com、api.example.com 共享 10.0.0.1:443），就无法识别该请求应路由到哪个虚拟主机。
开启 proxy_ssl_server_name on 后，Nginx 会在 TLS 握手时主动带上 SNI，值默认为 $proxy_host（即 proxy_pass 指定的域名），从而让上游能正确匹配 SSL 证书和 server 块。
本文共计627个文字，预计阅读时间需要3分钟。
当Nginx作为反向代理，将HTTPS请求转发给上游（例如CDN、回源、多域名共用同一IP等）时，可以直接输出结果：
为什么需要 proxy_ssl_server_name
Nginx 默认在与上游建立 HTTPS 连接时，不发送 SNI 扩展。这意味着即使你配置了 proxy_pass https://example.com，Client Hello 中的 SNI 字段仍是空的或使用 IP 地址。上游若托管多个 HTTPS 域名（如 blog.example.com、api.example.com 共享 10.0.0.1:443），就无法识别该请求应路由到哪个虚拟主机。
开启 proxy_ssl_server_name on 后，Nginx 会在 TLS 握手时主动带上 SNI，值默认为 $proxy_host（即 proxy_pass 指定的域名），从而让上游能正确匹配 SSL 证书和 server 块。