开启0-rtt后重放攻击是否被拦截，取决于协议支持、会话缓存、请求筛选、early-data透传与后端协同五环是否全部生效；任一缺失将导致静默降级或重放风险暴露。
开启 0-RTT 后遭遇重放攻击，不是“是否发生”的问题，而是“是否被拦截”的问题。Nginx 本身不阻止重放，只提供识别和传递信号的能力；真正的防护必须由配置组合与后端协同完成。排查重点不在日志里找“攻击记录”，而在验证四层防线是否完整生效。
确认 0-RTT 是否真实启用并命中
很多所谓“重放”实际是 0-RTT 根本没跑起来，导致请求走正常 TLS 握手（1-RTT），此时重放风险反而更低——但业务误以为开了 0-RTT 却未设防，隐患更大。需逐项验证：
-
协议与版本支持：检查
ssl_protocols是否同时包含TLSv1.2 TLSv1.3（仅写TLSv1.3会导致老客户端失败，但缺它则 PSK 不生成，0-RTT 彻底失效） -
会话缓存是否启用：
ssl_session_cache shared:SSL:10m和ssl_session_timeout 4h必须存在且生效；无此缓存，客户端拿不到 PSK，“票证”无法复用，0-RTT 自动降级 -
Early-Data 头是否透传：在 location 中添加
add_header X-Early-Data $ssl_early_data;，用 curl 或浏览器 DevTools 查看响应头是否出现X-Early-Data: 1 -
QUIC/HTTP/3 场景下额外验证：若启用了 HTTP/3，还需确认
listen 443 quic reuseport;及http_v3 on;已配置，否则 ssl_early_data 在 QUIC 下无效
检查非幂等请求是否被前端拦截
0-RTT 数据天然可重放，Nginx 必须在请求进入代理流程前就切断高危路径。不能依赖后端判断，否则重放包已抵达应用层。
- 对明确写操作的接口（如
/api/v1/submit、/login、/order），单独定义location块 - 在该块内使用
limit_except GET HEAD { deny all; }，强制拒绝 POST/PUT/DELETE 方法 - 确保该 location 未被更宽泛的通配规则覆盖（如
location /api/ { ... }不能笼统包含所有子路径） - 静态资源或只读接口（如
/status、/cities）可放开，但需确认其确实无副作用
验证 Early-Data 信号是否可靠透传至后端
Nginx 不校验重放，只负责把 Early-Data: 1 这个关键信号准确交给后端。若透传失败，后端无法区分 0-RTT 请求，所有防护逻辑形同虚设。
- 在 proxy_pass 前添加：
proxy_set_header Early-Data $ssl_early_data; - 后端收到请求时，检查原始 header 中是否存在
Early-Data: 1（注意不是X-Early-Data） - 避免在中间层（如 CDN、WAF）清洗或覆盖该 header；部分云厂商默认丢弃未知 header，需显式放行
- 可通过简单 echo 接口验证：返回全部请求头，确认
Early-Data字段值为1或空字符串
审查后端是否执行了对应安全决策
这是最后一道也是最关键的防线。后端收到 Early-Data: 1 后，必须立即执行业务级判断：
- GET/HEAD 请求且无状态变更（如查公开资料、拉取 JS/CSS）→ 可直接响应
- 任何含写意图的请求（登录、下单、改密、发消息）→ 必须拒绝，返回
425 Too Early，强制客户端降级重发 - 极少数允许 0-RTT 写的场景（如实时投票），必须叠加三要素：一次性 token + ≤5 秒时间窗 + 请求指纹（body hash + IP + UA）
- 严禁仅靠“时间戳+Nonce”防御 0-RTT 重放——这些机制在 0-RTT 阶段尚未建立连接上下文，无法保证原子性
不复杂但容易忽略：0-RTT 安全落地不是加一行 ssl_early_data on 就完事，而是协议、缓存、路由、透传、后端五环相扣。任一环节缺失，要么静默降级，要么敞口暴露重放风险。
