开启 ssl_early_data on 仅在协议、缓存、客户端与后端四重条件满足时，对幂等静态资源等特定请求实现“发包即响应”；需 Nginx≥1.15.5、OpenSSL≥1.1.1、启用会话复用，并由后端校验 Early-Data 标识、拒绝非幂等操作。
开启 ssl_early_data on 并不能让所有请求自动变快，它只在满足协议、缓存、客户端与后端四重条件时，对特定请求实现“发包即响应”。真正起效的关键，是精准识别适用场景，并确保整条链路协同就位。
基础配置必须严格闭环
光写一行指令远远不够，Nginx 必须同时满足以下硬性条件：
- Nginx ≥ 1.15.5（推荐 1.19.0+），OpenSSL ≥ 1.1.1（如 1.1.1w 或 3.0.x）
- 编译时启用
--with-http_ssl_module，且--with-openssl明确指向新版源码路径 - 在每个 HTTPS 的
server块中单独配置：ssl_protocols TLSv1.2 TLSv1.3;ssl_early_data on; - 必须启用会话复用机制：要么
ssl_session_cache shared:SSL:10m;，要么ssl_session_tickets on;（否则无法生成或恢复 PSK）
哪些请求真正受益于 0-RTT
0-RTT 不是通用加速器，它的价值集中在天然幂等、高频复用的资源上：
- CSS、JS、字体、图片等静态资源 —— 浏览器可在复用 PSK 后，把首个 CSS 请求直接塞进 ClientHello，服务器验证后立刻返回，TTFB 可压至接近网络延迟本身
- 公开 API（如获取公告、城市列表）—— 若不依赖身份上下文且无副作用，可直答
- 带 token 校验的只读接口（如
GET /api/user/profile）—— 只要校验逻辑幂等、无状态变更，就适配 - 登录页 HTML（若已缓存且不带动态 CSRF）—— 在 HTTP/3 场景下尤为明显，Initial 包即可携带
后端必须承担安全决策责任
Nginx 从不拦截或校验 Early Data，它只负责透传。风险全由后端承接：
- 通过
proxy_set_header Early-Data $ssl_early_data;显式将标识传递给上游服务 - 后端收到
Early-Data: 1时，必须立即拒绝任何非幂等操作：禁止执行登录、下单、转账、表单提交等 POST/PUT/DELETE 请求 - 对敏感接口，应统一返回
425 Too Early，引导客户端降级为 1-RTT 重发（注意 Chrome 对该状态码的自动重试行为不稳定，建议前端配合 JS 主动判断并重发） - 若业务强依赖 0-RTT 写操作（极少见），需自行实现防重放：一次性请求 ID + 时间窗口（≤ 5 秒）+ Redis 记录去重，三者缺一不可
快速验证是否真生效
仅看浏览器小锁图标或响应头容易误判，建议三步交叉确认：
- 抓包过滤
ClientHello，确认其扩展字段含early_data；再查紧接着的ServerHello后是否直接出现Application Data（未等客户端发Finished） - 浏览器访问后，在开发者工具 Security 标签页确认协议为 TLS 1.3，刷新一次，观察 Network 时间线中 “Waiting (TTFB)” 是否显著低于首次连接（高延迟网络下差异更明显）
- 在
log_format中加入$ssl_early_data字段记录，用awk统计日志中值为"1"的占比，可量化真实使用率
