直接配置 ssl_protocols TLSv1.3 可行但需 OpenSSL ≥ 1.1.1 且 Nginx ≥ 1.13.0，生产推荐 TLSv1.2 TLSv1.3 组合；须配 TLS 1.3 专用 cipher 套件并启用 OCSP Stapling 等加固措施。
直接写 ssl_protocols TLSv1.3 是可行的，但不是“一配就通”。它要求运行环境真正支持 TLS 1.3，且必须接受只服务新客户端的业务现实。生产环境更常用的是 TLSv1.2 TLSv1.3 组合，在安全与兼容之间取得平衡。
确认底层支持是否到位
SSL/TLS 协议能力不由 Nginx 版本单独决定，而是取决于它编译时绑定的 OpenSSL 库。即使 Nginx 是 1.25.x，若实际链接的是 OpenSSL 1.0.2，TLS 1.3 就不会生效。
- 运行
nginx -V 2>&1 | grep -i openssl，检查输出中 built with OpenSSL 后面的版本号，必须是 1.1.1 或更高（如 1.1.1w、3.0.13） - 注意：系统级
openssl version命令显示的是命令行工具版本，不能代表 Nginx 进程使用的库 - Nginx 自身需 ≥ 1.13.0（推荐 ≥ 1.14.1），但更重要的是 OpenSSL 支持和编译选项 —— 若为源码编译，需确保 configure 加了
--with-openssl-opt=enable-tls1_3
在 server 块中正确声明协议
ssl_protocols 指令作用于客户端到 Nginx 的前端 HTTPS 连接，必须放在 server 块内（不能只写在 http 块里而期望继承）。
- 严格仅用 TLS 1.3：
ssl_protocols TLSv1.3;—— 会拒绝所有不支持 TLS 1.3 的客户端（如 Windows 7 + IE11、Android 4.x、部分 Java 8 默认环境、老旧 IoT 设备） - 推荐生产配置：
ssl_protocols TLSv1.2 TLSv1.3;—— 兼容绝大多数现代设备，同时允许 TLS 1.3 自动协商 - 切勿写成
TLSv1 TLSv1.1 TLSv1.2 TLSv1.3，旧协议已存在严重漏洞，应明确禁用
同步更新 cipher 套件与相关参数
TLS 1.3 彻底重构了密钥协商机制，传统 cipher suite 名称（如 ECDHE-RSA-AES256-GCM-SHA384）在 TLS 1.3 中无效，混入会导致协商异常或静默降级。
- 使用 TLS 1.3 专用套件名：
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256; - 避免任何不含
TLS_前缀的套件（如AES256-GCM-SHA384、ECDHE-ECDSA-等均属 TLS 1.2） -
ssl_prefer_server_ciphers off;是 TLS 1.3 下的推荐设置，该指令在 TLS 1.3 中已无实际影响，但保留更清晰
配套加固不可省略
开启 TLSv1.3 只是起点，真实安全性还需其他关键配置协同：
- 启用 OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 1.1.1.1 valid=300s; resolver_timeout 5s;—— 减少证书吊销验证延迟，防止隐私泄露 - 强制 HTTPS 升级：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;—— 防止协议降级攻击 - 日志中记录协议版本便于观察：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$ssl_protocol" "$ssl_cipher"';
