平滑迁移到 tls 1.3 需分阶段验证、确认 openssl ≥1.1.1 支持、渐进调整 ssl_protocols 和 cipher 套件、配套启用 ocsp stapling/hsts/会话优化，并通过灰度测试与回滚机制保障稳定。
平滑迁移到 TLS 1.3 不是改一行配置就能完成的事，关键在于分阶段验证、控制影响范围，并确保底层真实就绪。直接删掉 TLS 1.0/1.1 或只加 ssl_protocols TLSv1.3 很容易导致老客户端断连或静默降级，反而引发线上问题。
确认运行时 OpenSSL 真正支持 TLS 1.3
很多人卡在这一步：Nginx 版本 ≥1.13.0，但实际不生效。根本原因是 Nginx 编译时绑定的 OpenSSL 版本不够。
- 执行
nginx -V 2>&1 | grep -i openssl，输出必须含 OpenSSL 1.1.1w 或 OpenSSL 3.0.13 等 ≥1.1.1 的版本号；若显示 1.0.2u 或 1.1.0l，即使 Nginx 是 1.18 也无效 - 运行
openssl ciphers -v 'TLSv1.3'，应至少列出三条套件（如TLS_AES_256_GCM_SHA384），否则说明系统 OpenSSL 未启用 TLS 1.3 - Ubuntu/Debian 用户注意：
nginx包默认不带新版 OpenSSL，建议换用nginx-full（22.04+）或自编译；CentOS/RHEL 7 需启用 EPEL 并安装nginx-mod-http-ssl
分阶段调整 ssl_protocols 和 cipher 套件
不能跳过兼容期直接切到仅 TLSv1.3，尤其当站点仍有 Android 4.4、IE11 等访问时。
- 第一阶段（观察）：写成
ssl_protocols TLSv1.2 TLSv1.3;，搭配 TLS 1.3 专用套件：ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256; - 第二阶段（评估）：通过日志或监控统计 TLS 1.3 握手占比（如 Nginx 变量
$ssl_protocol），确认主流客户端已稳定协商成功 - 第三阶段（切换）：确认无风险后，再改为
ssl_protocols TLSv1.3;—— 此时务必同步关闭所有非 TLS_ 开头的 cipher，避免降级失败 - 严禁混用旧 cipher（如 ECDHE-RSA-AES256-GCM-SHA384），否则 Nginx 会静默拒绝 TLS 1.3 握手
配套加固配置必须同步启用
TLS 1.3 协议本身不解决证书吊销、中间人降级等问题，以下配置缺一不可：
- OCSP Stapling：减少握手延迟并防隐私泄露
ssl_stapling on; ssl_stapling_verify on;<br>resolver 8.8.8.8 1.1.1.1 valid=300s; resolver_timeout 5s;
- HSTS 强制 HTTPS：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - 会话优化（支撑 0-RTT）：
ssl_session_tickets on; ssl_session_timeout 1d;<br>ssl_ecdh_curve X25519:secp384r1;
- 显式关闭已失效指令：
ssl_prefer_server_ciphers off;（TLS 1.3 下该指令无意义，设为 on 反而干扰协商）
灰度验证与回滚机制
批量修改前，先选低流量站点做闭环验证：
- 用
curl -v --tlsv1.3 https://yoursite.com和openssl s_client -connect yoursite.com:443 -tls1_3主动测试握手路径 - 在 Nginx 中用
map+if控制灰度范围（如只对指定 IP 段或请求头启用新配置） - 监控真实 TLS 握手成功率、HTTP 状态码分布、OCSP 响应时间，确认无连接失败或降级
- 准备秒级回滚脚本：备份旧配置 +
nginx -t && nginx -s reload一键还原
