ssl_early_data on 是 HTTP/3 实现真正 0-RTT 请求的必要开关，因 QUIC 将 TLS 与连接建立深度耦合，客户端可在 Initial 包中携带加密应用数据，而该指令是 Nginx 接收并处理该数据的唯一入口；HTTP/2 下 0-RTT 为可选且受限于 TCP 重建开销，HTTP/3 下则为协议原生能力，缺此配置即强制降级至 1-RTT。
在 HTTP/3 场景下，ssl_early_data on 是实现真正 0-RTT 请求的关键开关——但它不是开就完事，必须配合 QUIC 连接生命周期、TLS 1.3 会话恢复机制和应用层数据安全策略协同工作，否则可能被忽略、降级，甚至引发重放攻击。
为什么 ssl_early_data 在 HTTP/3 中比 HTTP/2 更重要
HTTP/3 基于 QUIC，而 QUIC 将 TLS 握手与连接建立深度耦合。客户端在发送 Initial 包时，若已缓存上一次会话的 PSK（Pre-Shared Key），就能直接加密并携带应用数据（如首屏 HTML 请求）。此时 ssl_early_data on 告诉 Nginx：允许接收并处理这部分“提前抵达”的加密载荷。
- HTTP/2 下 0-RTT 是 TLS 层可选能力，且受限于 TCP 连接重建开销；
- HTTP/3 下 0-RTT 是 QUIC 协议原生能力，
ssl_early_data是 Nginx 接收它的唯一入口； - 没有它，即使客户端发了 0-RTT 数据，Nginx 默认丢弃，强制回退到 1-RTT 流程。
启用 ssl_early_data 的最小可行配置
仅加一行 ssl_early_data on; 不够，需配套三项基础设置：
-
ssl_protocols TLSv1.3;—— HTTP/3 强制要求 TLS 1.3，早于该版本不支持 PSK 和 0-RTT； -
ssl_session_cache shared:SSL:10m;—— 必须启用会话缓存，QUIC 的 PSK 依赖于此生成； -
add_header Early-Data $ssl_early_data;—— 向上游或日志暴露是否命中 0-RTT，便于调试和监控。
完整 server 块示例：
server {listen 443 ssl http3;
listen 443 quic reuseport;
ssl_certificate cert.pem;
ssl_certificate_key key.pem;
ssl_protocols TLSv1.3;
ssl_early_data on;
ssl_session_cache shared:SSL:10m;
add_header Early-Data $ssl_early_data;
location / {
proxy_pass http://backend;
proxy_set_header Early-Data $ssl_early_data;
}
}
0-RTT 数据的安全边界与规避重放风险
0-RTT 数据天然可被网络中间设备截获并重放，因此不能用于修改状态的操作（如 POST 表单提交、支付请求）。
- 只应在
GET或幂等接口中启用，例如首屏 HTML、关键 CSS/JS 资源请求； - Nginx 不自动校验重放，需业务层配合：对含敏感参数的 URL 加时间戳+签名，或用
map指令拦截高危路径； - 可通过
$ssl_early_data变量做条件路由：
map $ssl_early_data $block_early {
"1" "yes";
"0" "no";
}
if ($block_early = "yes") {
return 425;
}
验证是否真走通了 0-RTT
不能只看浏览器 Network 面板显示 h3，要确认请求是否在握手包里发出：
- 用 curl 测试：
curl -v --http3 --tlsv1.3 https://yoursite.com/，观察输出中是否有Early data was sent； - 在 Nginx access_log 中添加
$ssl_early_data字段，真实请求日志应出现1； - 抓包分析（Wireshark + QUIC 解密）：过滤
quic.packet_type == "Initial"，查看其 payload 是否含 HTTP/3 STREAM 帧。
