如何配置 proxy_ssl_server_name 开启：解决后端微服务多证书环境下的 SNI 匹配-Nginx-PHP中文网

必须显式写proxy_ssl_server_name on，因为Nginx默认关闭SNI扩展，导致Client Hello不携带server_name，使依赖SNI的HTTPS后端（如Traefik、ALB、多域名Nginx）只能返回默认证书或中断连接，引发502、SSL握手失败等错误。

如何配置 proxy_ssl_server_name 开启：解决后端微服务多证书环境下的 sni 匹配

不开启 proxy_ssl_server_name on，Nginx 与 HTTPS 后端建立 TLS 连接时根本不会发 SNI 字段——这是 502、握手失败、证书校验错误的底层原因，不是配置顺序或证书路径问题。

为什么必须显式写 `proxy_ssl_server_name on`

Nginx 默认关闭 SNI 扩展，哪怕 proxy_pass 指向的是 https://api.example.com，它也只解析 DNS 得到 IP，然后用该 IP 建立 TLS 连接，Client Hello 中不含 server_name。上游若依赖 SNI（如 Istio ingress、Traefik、ALB、多域名共 IP 的 Nginx），就只能返回默认证书或直接中断连接。

错误日志典型特征：SSL_do_handshake() failed、tlsv1 alert internal error、temporarily disabled while SSL handshaking to upstream
该指令仅在 proxy_pass 使用 https:// 协议时生效；若回源走 HTTP，整个 proxy_ssl_* 系列配置被忽略
必须放在 location 或 upstream 对应的 proxy_pass 同一作用域内，不能只写在 http 块顶层

`proxy_ssl_name` 必须动态匹配请求域名，不能硬编码

仅开启 proxy_ssl_server_name on 不够：Nginx 还得知道“该发哪个域名过去”。proxy_ssl_name 就是这个值，它决定 Client Hello 中的 SNI 字段内容。

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

推荐用 proxy_ssl_name $host;：已标准化，不含端口，来自 Host 请求头且经 Nginx 解析（如 shop-a.com:8443 → shop-a.com）
若 CDN 回源改写了 Host（如 Cloudflare 默认把 Host 改成源站域名），$host 就失真，此时应启用 CDN 的“透传原始 Host”并改用 proxy_ssl_name $http_x_forwarded_host;
禁止写死 proxy_ssl_name "api.example.com"; 除非所有请求都指向同一后端域名；多域名场景下硬编码会导致其他请求 SNI 错配
注意：proxy_ssl_name 的值必须和 proxy_set_header Host 保持一致，否则部分严格网关（如某些 Envoy 配置）会拒绝请求

upstream 场景下 `proxy_ssl_name` 必须是字符串字面量

当你用 upstream 做负载均衡（例如对接多个 api-01.internal:443、api-02.internal:443），Nginx 不会自动从 upstream 名称推导 SNI 值——它只取 IP，SNI 仍需显式指定。

upstream 块里只需定义地址：upstream api_backend { server api.internal:443; }
在 location 中使用时，proxy_ssl_name 必须写成带引号的字符串：proxy_ssl_name "api.internal";（不能是 $host 或变量）
这是因为 upstream 解析发生在变量展开之前，Nginx 无法在运行时将变量注入 SNI 字段；只有静态字符串才被允许
同时仍要保留 proxy_ssl_server_name on; 和 proxy_set_header Host "api.internal";

验证 SNI 是否真正发出，别只信配置文件

配置写对了 ≠ 实际生效。SNI 是 TLS 层行为，必须从协议层面确认。

最可靠方式：在上游服务器（比如另一台 Nginx）开启 debug 日志：error_log /var/log/nginx/error.log debug;，触发请求后搜索日志中的 client sent server name 行，看输出是否为你期望的域名
快速模拟：在 Nginx 机器上执行 openssl s_client -connect 10.0.0.100:443 -servername shop-a.com，观察返回的证书 Subject CN 或 SAN 是否匹配 shop-a.com
抓包辅助判断：用 tcpdump -i any port 443 -w test.pcap 抓 Nginx 到上游的流量，Wireshark 打开后过滤 tls.handshake.type == 1，展开 Client Hello 查看 Server Name Indication extension 字段
常见盲区：上游服务本身不支持 SNI（如旧版 Nginx