仅在 proxy_ssl_protocols 中写 TLSv1.3 无法强制生效，必须同时配置 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 错误或静默降级。要让 Nginx 在回源（即反向代理到后端 HTTPS 服务）时稳定、安全地只走 TLS 1.3，必须同时满足协议限制、证书验证、SNI 和信任链四个条件。
必须只写 TLSv1.3，且位置精准
该指令不继承全局 ssl_protocols，必须显式配置在生效的作用域内：
- 放在
upstream块内部最稳妥，便于复用和审计 - 或放在具体
location中、proxy_pass https://...指令附近 - 绝对不要混入
TLSv1.2，例如TLSv1.2 TLSv1.3—— 这会允许协商降级，失去强制性 - 正确写法：
proxy_ssl_protocols TLSv1.3;
必须配齐四项验证指令
仅限协议版本不够，Nginx 要完成 TLS 1.3 握手并校验证书，以下四条缺一不可：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
-
proxy_ssl_verify on;：启用上游证书合法性检查 -
proxy_ssl_trusted_certificate /path/to/ca-bundle.crt;：指向包含后端签发 CA 的 PEM 文件（不能是空文件或路径错误） -
proxy_ssl_name "backend.example.com";：显式声明期望的域名，用于匹配证书 SAN 字段（即使proxy_pass写的是 IP，也必须设） -
proxy_ssl_server_name on;：启用 TLS SNI 扩展，确保握手时发送正确的主机名
密钥套件必须严格限定为 TLS 1.3 原生组合
TLS 1.3 废弃了传统协商机制，只接受 5 种固定组合，Nginx 不会读取旧式套件：
- 推荐配置：
proxy_ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256"; - 禁止混入任何带
ECDHE-RSA、AES256-GCM-SHA384等标识的 TLS 1.2 套件，否则可能握手失败或被后端拒绝 - 可不配置
proxy_ssl_ciphers，Nginx 会自动选用兼容组合；但显式声明更可控、更易审计
验证是否真实生效，不能只靠语法检查
配置重载后，需实测确认：
- 临时开启调试日志：
error_log /var/log/nginx/error.log debug;，观察是否有SSL_do_handshake() failed或certificate verify failed - 用
curl -Iv https://your-domain.com查看响应头及 TLS 版本输出 - 抓包验证：在 Nginx 服务器上对上游地址执行
tcpdump -i any -w upstream.pcap port 443，用 Wireshark 检查supported_versions和实际协商结果 - 重点核对三项细节：证书 SAN 是否匹配
proxy_ssl_name；proxy_ssl_trusted_certificate文件权限是否为 600 且 worker 进程可读；proxy_ssl_server_name是否确实开启
