必须同时配置proxy_ssl_verify on、proxy_ssl_trusted_certificate、proxy_ssl_name和proxy_ssl_server_name on四项指令，缺一不可；且proxy_ssl_ciphers须严格限定为TLS 1.3原生套件，否则易致502或连接中断。
直接在 proxy_ssl_protocols 中只写 TLSv1.3 并不能“强制”成功，反而容易导致 502 错误或连接中断。真正安全、稳定的回源 TLS 1.3 升级，依赖的是协议、证书验证、SNI 和信任链四者的协同生效。
必须配齐的四项指令，缺一不可
仅设置 proxy_ssl_protocols TLSv1.3; 是无效的。Nginx 要完成对后端 HTTPS 服务的 TLS 1.3 握手并校验证书，以下四条必须同时存在且配置正确：
-
proxy_ssl_verify on;—— 启用上游证书合法性校验 -
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;—— 指向包含可信根 CA（及必要中间 CA）的 PEM 文件，不能留空或指向错误路径 -
proxy_ssl_name "backend.example.com";—— 显式声明期望的后端域名，用于匹配证书 Subject Alternative Name（SAN），即使proxy_pass写的是 IP 地址也必须设此项 -
proxy_ssl_server_name on;—— 启用 TLS SNI 扩展，确保 Nginx 在握手时向后端发送正确的主机名，否则泛域名或云服务类后端会拒绝连接
协议与密钥套件需严格匹配 TLS 1.3 规范
TLS 1.3 彻底废弃了传统 cipher suite 协商机制，只允许五种标准化组合（如 TLS_AES_256_GCM_SHA384）。若你在 proxy_ssl_ciphers 中混入 TLS 1.2 套件（例如 ECDHE-RSA-AES256-GCM-SHA384），Nginx 不会报错，但实际连接可能降级失败或被后端拒绝。
- 推荐精简配置：
proxy_ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256; - 务必移除所有含
_SHA384以外后缀、或带ECDHE/RSA密钥交换标识的旧套件 - 搭配
proxy_ssl_protocols TLSv1.3;使用时，上述 cipher 列表是唯一兼容选项
验证与排障的关键动作
配置完成后，不能只靠 nginx -t 判断是否生效。真实 TLS 握手失败往往静默返回 502，需主动验证：
- 用
curl -Iv https://your-domain.com观察响应头和 TLS 版本输出，确认是否走 TLS 1.3 - 检查 error log：临时提升日志级别为
error_log /var/log/nginx/error.log debug;，可捕获SSL_do_handshake() failed或certificate verify failed的具体原因 - 重点核对三项细节：证书 SAN 是否匹配
proxy_ssl_name值；proxy_ssl_trusted_certificate文件权限是否为 600 且 Nginx worker 进程可读；后端服务是否真实支持 TLS 1.3（如 Nginx 1.13+ + OpenSSL 1.1.1+）
不建议跳过兼容性过渡阶段
除非你 100% 确认所有后端服务均稳定支持 TLS 1.3 且无中间代理干扰，否则上线初期建议先设为：
proxy_ssl_protocols TLSv1.2 TLSv1.3;待日志中观察数日，确认所有上游连接均协商到 TLS 1.3 后，再收紧为仅 TLSv1.3。这能避免因某台后端版本滞后或配置遗漏引发批量故障。
