Nginx 升级 TLS 1.3 需先确认运行时 OpenSSL ≥1.1.1，再分三阶段调整 ssl_protocols：TLSv1.2 TLSv1.3（观察）、统计占比（评估）、仅 TLSv1.3（切换），并严格配置 TLS 1.3 专用 cipher 套件。
要让 Nginx 从旧版 TLS 平滑升级到 TLS 1.3，关键不是简单删掉低版本协议，而是分阶段验证兼容性、控制影响范围，并确保底层依赖真正就绪。
确认运行时 OpenSSL 版本是否达标
Nginx 自身不处理加密逻辑，它调用系统或编译时链接的 OpenSSL 库。即使 nginx -v 显示是 1.14+，若 nginx -V 输出中 built with OpenSSL 后面的版本低于 1.1.1（如 1.0.2k），TLS 1.3 就无法启用。
- 运行 nginx -V | grep OpenSSL 查看实际绑定的 OpenSSL 版本
- 若版本过低，需重新编译 Nginx 并指定新版 OpenSSL 路径，或更换为系统自带高版本 OpenSSL 的发行版包（如 Ubuntu 20.04+/CentOS 8+ 的官方 nginx 包）
- 不要仅依赖 openssl version 命令结果——它显示的是命令行工具版本，未必与 Nginx 运行时一致
分阶段调整 ssl_protocols 指令
直接写 ssl_protocols TLSv1.3 会导致所有不支持 TLS 1.3 的客户端（如 Windows 7 + IE11、Android 4.x、部分老旧 IoT 设备）连接失败。应按以下节奏推进：
- 第一阶段（观察期）：配置为 ssl_protocols TLSv1.2 TLSv1.3，保持向后兼容，同时在日志中添加 $ssl_protocol 变量记录每次握手使用的协议版本
- 第二阶段（评估期）：分析数日访问日志，统计 TLS 1.3 使用占比。若超过 95% 且无关键业务客户端投诉，可准备下一步
- 第三阶段（切换期）：改为 ssl_protocols TLSv1.3，并同步检查 ssl_ciphers 是否只保留 TLS 1.3 专用套件（如 TLS13-AES-256-GCM-SHA384）
配套必须更新的 cipher 配置
TLS 1.3 彻底移除了传统 cipher suite 的协商机制，它只允许五种标准化密钥交换+加密组合。如果 ssl_ciphers 中混入了 TLS 1.2 的套件（如 ECDHE-RSA-AES256-GCM-SHA384），Nginx 启动可能不报错，但客户端协商会降级或失败。
- 推荐写法：ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256
- 避免使用含 “TLS” 以外前缀的套件名（如 EECDH、RSA、AES256-SHA 等），它们属于 TLS 1.2 及更早版本
- 无需再写 ssl_prefer_server_ciphers on；TLS 1.3 下该指令已失效
验证是否真正生效
浏览器开发者工具的“安全”标签页常显示“TLS 1.3”，但这只是客户端声明。真实协议版本由服务端最终决定。可靠验证方式如下：
- 用 curl 测试：curl -I --tlsv1.3 --tls-max 1.3 https://yoursite.com（成功返回 HTTP 状态码即表示服务端接受 TLS 1.3）
- 用 openssl s_client：openssl s_client -connect yoursite.com:443 -tls1_3，查看输出中是否有 "Protocol : TLSv1.3"
- 禁用 TLS 1.2 客户端测试（如临时修改本地 Chrome 启动参数 --ssl-version-min=tls1.3），确认旧协议请求是否被拒绝
