nginx启用tls 1.3的0-rtt需满足四重条件：nginx≥1.13.0（推荐1.24.x+）、openssl≥1.1.1、配置ssl_early_data on与tlsv1.3、后端校验early-data头防重放。
直接在 Nginx 负载均衡层启用 TLS 1.3 的 0-RTT，看似能“秒建连接”，实则是把安全决策权部分交给了网络边缘。它不是简单的开关选项，而是一套需要上下游协同、分层设防的机制。Nginx 在其中承担 TLS 层的解密与标识职责，但绝不包揽全部安全责任。
底层支持是硬门槛，缺一不可
0-RTT 不会因配置存在而自动生效，它极度依赖运行时环境是否真正就绪：
- Nginx 必须 ≥ 1.13.0（推荐 1.24.x 或更高），且需用 OpenSSL 1.1.1+ 编译——执行 openssl version 确认不是 1.0.2 或 1.1.0
-
ssl_ciphers 必须只写 TLS 1.3 原生套件，例如：
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
混入任何 TLS 1.2 套件（如 ECDHE-RSA-AES256-SHA）会导致协商异常或静默降级 - 必须开启会话票据：ssl_session_tickets on，且 ssl_session_timeout 建议设为 ≥ 1d；否则 PSK 无法生成，0-RTT 失去凭据基础
- 证书与私钥路径权限、SELinux/AppArmor 策略需允许 Nginx 读取——权限不足不会报错，但 0-RTT 将静默失效
Nginx 只做“识别”和“转发”，不代行业务校验
Nginx 的角色非常明确：完成 TLS 层的早期数据解密，并通过变量暴露关键上下文，但绝不替代后端判断请求是否可信：
- 启用 ssl_early_data on 后，可通过 $ssl_early_data 变量获知该请求是否走 0-RTT 路径（值为 1）
- 它不校验时间戳、不验证 nonce、不拦截非幂等方法——这些必须由后端应用实现
- 典型做法是在反向代理头中透传标识：
proxy_set_header X-Early-Data $ssl_early_data; - 若后端未检查此头、或未对 POST/PUT 等操作做二次鉴权，则 0-RTT 成为重放攻击的直通通道
重放风险不可回避，必须靠业务层闭环防御
0-RTT 的本质是“信任预支”，其安全代价清晰可见：
- 攻击者截获一次 0-RTT 请求，可在票证有效期内无限次重放（窗口期通常为数小时至一天）
- 早期数据不具备前向保密性——若服务器长期 PSK 密钥泄露，历史通信可被批量解密
- 仅适用于幂等操作：GET 类资源获取、配置拉取、静态内容查询等；登录、支付、下单等必须拒绝 0-RTT 或强制二次校验 session/token
- 建议后端引入单次使用 Token 或时间窗口校验（如请求距票据签发 ≤ 300 秒），并配合 Redis 实现 nonce 去重
分布式部署下，PSK 管理比 Session Ticket 更复杂
在多实例负载均衡场景中，0-RTT 对密钥一致性提出更高要求：
- TLS 1.2 的 Session Ticket 依赖服务端加密密钥同步；而 TLS 1.3 的 PSK 由客户端存储，理论上无需服务端共享——但前提是所有节点使用同一组 PSK 加密密钥
- Nginx 默认使用随机生成的 ticket key，滚动更新或扩缩容时易导致新旧节点 PSK 不兼容，表现为 0-RTT 失效或握手回退
- 生产环境应显式配置固定密钥：
ssl_session_ticket_key /etc/nginx/ticket.key;（二进制文件，32 字节 AES 密钥） - 高可用架构中，建议通过 Vault 或配置中心统一分发和轮换 ticket key，避免密钥漂移
