必须同时满足Nginx≥1.15.5、OpenSSL≥1.1.1且编译启用TLS 1.3，系统内核与glibc兼容；需在server块中配置ssl_protocols TLSv1.2 TLSv1.3、专用cipher套件、http2监听，并谨慎启用ssl_early_data。
确认底层环境是否就绪
TLS 1.3不是改几行配置就能用的，它依赖Nginx和OpenSSL的版本协同。必须同时满足：
- Nginx ≥ 1.15.5（官方明确要求0-RTT支持的最低版本），推荐1.19.0或更高稳定版
- OpenSSL ≥ 1.1.1（如1.1.1w、3.0.x），且编译时已启用TLS 1.3支持
- 系统内核与glibc兼容新版OpenSSL（CentOS 7.6+/Ubuntu 18.04+通常达标）
验证命令：
nginx -V 2>&1 | grep -i openssl —— 查看编译所用OpenSSL路径与版本
openssl version —— 确认运行时OpenSSL版本是否≥1.1.1
nginx -v —— 检查Nginx主版本号
在server块中启用TLS 1.3协议
仅修改全局设置无效，必须在具体HTTPS server配置中显式声明：
- 添加ssl_protocols TLSv1.2 TLSv1.3：保留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.2专属套件（如ECDHE-RSA-AES256-SHA），否则可能干扰协商 - 开启ALPN支持：listen指令后加http2（如listen 443 ssl http2），让客户端在TLS握手阶段就协商应用层协议
开启0-RTT并处理early data风险
0-RTT能将首包即发应用数据，但代价是重放攻击风险——Nginx不拦截、不校验，只负责透传。
- 在对应server块中添加：ssl_early_data on
- 确保会话复用机制开启（session tickets或cache），否则无法生成/恢复PSK：
ssl_session_tickets on 或 ssl_session_cache shared:SSL:10m - 后端必须识别Early-Data: 1请求头：
通过proxy_set_header Early-Data $ssl_early_data显式传递给上游
应用层需拒绝0-RTT下的非幂等操作（如POST登录、PUT更新、DELETE资源），或返回425 Too Early强制降级为1-RTT - 对GET等幂等请求可直接响应，无需额外防护
快速验证是否生效
部署后建议多角度交叉验证：
- 浏览器端：打开开发者工具 → Security标签页，查看连接协议是否显示“TLS 1.3”
-
命令行：
openssl s_client -connect your-domain.com:443 -tls1_3 —— 成功连接即表示协议支持
curl -I --http2 -k https://your-domain.com —— 观察响应头是否含alt-svc: h2及TLS版本信息 -
抓包分析（Wireshark）：
过滤tls.handshake.type == 11（End of Early Data）确认0-RTT流程
或观察ClientHello中是否存在early_data扩展字段
