开启ssl_early_data需满足协议、缓存、客户端与后端四重条件，仅配置on不够；Nginx须≥1.15.5、OpenSSL≥1.1.1，启用TLSv1.3及会话复用；CSS/JS等幂等静态资源最适配0-RTT；后端须识别Early-Data头并安全放行或拒接非幂等请求；PSK丢失或中间件不支持会导致降级。
直接开启 ssl_early_data on 并不能自动让首屏加载变快——它只在满足协议、缓存、客户端与后端四重条件时，对部分请求实现“发包即响应”。真正起效的关键，在于精准识别哪些资源适合走 0-RTT，并确保整条链路不破坏其前提。
基础配置必须到位
仅加一行指令远远不够。Nginx 需同时满足：
- Nginx ≥ 1.15.5（推荐 1.19.0+），OpenSSL ≥ 1.1.1（自带 TLS 1.3 支持）
- 编译时启用
--with-http_ssl_module和指定新版 OpenSSL 路径 - server 块中明确写入：
ssl_protocols TLSv1.2 TLSv1.3;ssl_early_data on; - 会话复用必须打开：
ssl_session_cache shared:SSL:10m;或ssl_session_tickets on;（否则无法生成/恢复 PSK）
CSS、JS、图片等静态资源最适配 0-RTT
这类请求天然幂等，不修改状态，且用户二次访问时高频触发。浏览器在复用前次连接的 PSK 后，可直接在 ClientHello 中携带 early_data 扩展，把首个 CSS 请求“塞进握手包里”发出。服务器验证 PSK 合法后，无需等待 Finished 消息，立刻返回响应——TTFB 可压到接近网络延迟本身。
示例场景：用户刷新页面，HTML 已缓存，但 CSS 文件需重新拉取。若该 CSS 请求走 0-RTT，比常规 TLS 1.3 的 1-RTT 握手快一个往返周期，在 100ms 高延迟链路上，TTFB 可从 ~140ms 降至 ~40ms。
后端必须识别并安全放行
Nginx 不校验 0-RTT 数据，只透传。关键动作全在后端：
- 通过
proxy_set_header Early-Data $ssl_early_data;把标识传给上游 - 后端收到
Early-Data: 1时，对 GET 类静态资源可直答；对非幂等请求（如登录接口、表单提交）应返回425 Too Early，强制降级为 1-RTT 重发 - 若业务强依赖 0-RTT 写操作（极少见），必须引入一次性 token、时间戳窗口或请求指纹去重机制
别忽略失效场景和误判风险
很多情况下 0-RTT 根本不会触发，却误以为配置失败：
- 用户清理浏览器缓存或换设备 → PSK 丢失，退化为 1-RTT
- 中间代理（如企业防火墙、老旧 CDN）不支持 TLS 1.3 early_data 扩展 → 握手被截断或降级
- 仅靠响应头
Early-Data: 1判断不可靠，需三步交叉确认：抓包看 ClientHello 是否含 early_data 扩展 + ServerHello 后是否紧接 Application Data + 浏览器 Security 标签页确认协议为 TLS 1.3 且刷新后 TTFB 显著下降
