启用ssl_early_data需满足四重条件：协议（TLSv1.3+）、会话复用（ssl_session_cache或tickets）、客户端缓存PSK、后端防护重放；仅配ssl_early_data on无效。
在 TLS 1.3 下启用 ssl_early_data，确实能让部分请求实现“发包即响应”，但它的零延迟效果不是配置完就自动生效的——必须同时满足协议支持、会话复用、客户端行为和后端防护四方面条件。
基础配置必须到位
仅加 ssl_early_data on; 不够，需同步完成以下三项：
-
TLS 版本强制限定：必须包含
ssl_protocols TLSv1.3;（HTTP/3 场景下甚至需禁用 TLS 1.2）； -
会话缓存必须启用：如
ssl_session_cache shared:SSL:10m;或ssl_session_tickets on;，否则无法生成/恢复 PSK，0-RTT 就无从谈起； - Nginx 版本与 OpenSSL 匹配：Nginx ≥ 1.15.5（推荐 1.19.0+），OpenSSL ≥ 1.1.1，且编译时需显式指定 OpenSSL 路径并启用 SSL 模块。
客户端与网络环境决定是否真走 0-RTT
即使服务端全配对，客户端也得“配合”才能触发：
- 浏览器需支持 TLS 1.3 并已缓存上一次连接的 PSK（通常需用户至少访问过一次该站点）；
- 不能处于隐私模式或刚清空缓存状态；
- 若使用 CDN，CDN 节点本身也必须支持 TLS 1.3 和 0-RTT，否则会在中间断掉 early_data 扩展。
后端必须主动识别并防护重放
Nginx 不校验也不拦截 0-RTT 请求，只负责透传。关键安全逻辑全在后端：
- 通过
proxy_set_header Early-Data $ssl_early_data;把标识传给上游； - 后端收到
Early-Data: 1时，禁止执行非幂等操作（如登录、下单、修改数据库）； - 对 GET 类静态资源或公开 API 可直接响应；对敏感接口建议返回
425 Too Early，引导客户端降级为 1-RTT 重发； - 若必须支持 0-RTT 写操作，需叠加一次性 token、时间戳窗口或请求指纹去重等应用层机制。
如何确认是否真正生效
别只看响应头或日志，建议三步交叉验证：
- 抓包过滤
ClientHello，确认其携带early_data扩展； - 再查紧接着的
ServerHello后是否立刻出现加密的Application Data（未等客户端发Finished）； - 浏览器开发者工具中，Security 标签页确认协议为 TLS 1.3，再刷新页面，观察 Network 面板中 TTFB 是否明显低于首次连接（尤其在高延迟网络下更易察觉）。
