必须同时配置proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name on四项指令，缺一不可；且proxy_ssl_ciphers须严格限定为TLS 1.3原生套件，否则易致502或连接中断。
仅在
中写
无法满足合规要求，也不代表实际启用成功。合规性依赖协议、证书验证、SNI 和密钥套件四者协同生效，缺一不可。
必须配齐的四项基础指令
回源链路要通过 TLS 1.3 完成可信握手，以下配置必须同时存在且正确：
—— 启用上游证书合法性校验，禁用则失去身份信任基础
—— 指向含可信根 CA 及必要中间 CA 的 PEM 文件，路径需可读、权限建议设为 600
—— 显式声明期望的后端域名，用于匹配证书 SAN 字段；即使
写的是 IP 地址也必须设置
—— 启用 TLS SNI 扩展，确保 Nginx 在握手时向后端发送正确的主机名，否则多租户或泛域名场景必然失败
协议与密钥套件必须严格匹配 TLS 1.3 规范
TLS 1.3 已废弃传统协商机制，只接受五种标准化加密套件。混入 TLS 1.2 套件会导致静默降级或连接中断：
推荐精简配置：
必须移除所有含
以外后缀（如
）、或带
/
密钥交换标识的旧套件
必须与上述 cipher 列表搭配使用，单独设置无意义
动态 SNI 配置适配多租户与云平台回源
当回源目标为共享 IP 的云网关、SaaS 后端或 CDN 源站时，SNI 必须携带用户真实访问域名，而非静态值：
在
块中启用：
并设置
若 CDN 或前端网关改写了 Host 头，改用
，并补上
避免硬编码域名，否则无法支撑多租户或泛域名业务场景
验证是否真正符合合规要求
配置语法正确不等于运行时达标。需主动验证三项关键事实：
用
查看响应头和 TLS 版本输出，确认握手使用 TLS 1.3
临时提升日志级别：
，搜索
或
等线索
核对：证书 SAN 是否包含
值；
文件权限与路径是否准确；上游服务是否支持 TLS 1.3 + SNI
proxy_ssl_protocolsTLSv1.3proxy_ssl_verify on;proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;proxy_ssl_name "backend.example.com";proxy_passproxy_ssl_server_name on;proxy_ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;_SHA256_SHA384ECDHERSAproxy_ssl_protocols TLSv1.3;locationproxy_ssl_server_name on;proxy_ssl_name $host;proxy_ssl_name $http_x_forwarded_host;proxy_set_header X-Forwarded-Host $host;curl -Iv https://your-domain.comerror_log /var/log/nginx/error.log debug;SSL_do_handshake() failedcertificate verify failedproxy_ssl_nameproxy_ssl_trusted_certificate