0-RTT需分层防护：Nginx层限制方法、透传标识、路径隔离；后端对非幂等请求返回425；CDN可增强校验。所有POST/PUT/DELETE/PATCH及敏感接口禁用0-RTT，仅静态资源和公开API可用。
0-RTT 能提速，但重放攻击风险真实存在——它不是理论威胁，而是已导致多次重复扣款、重复下单的真实事故。加固不能只靠“关掉0-RTT”，而要分层设防：在Nginx层拦截和标记，在后端逻辑中做决策，在协议与业务设计上补足短板。
明确哪些请求绝对禁止走0-RTT
非幂等操作（即执行多次会产生不同结果的操作）必须拒绝0-RTT。这不是建议，是硬性边界：
- 所有 POST / PUT / DELETE / PATCH 请求一律不接受 Early Data
- 登录、密码修改、支付提交、订单创建、消息发送等接口路径，应强制降级为 1-RTT
- 静态资源（如 CSS/JS/图片）、公开 API（如获取公告、城市列表）可保留0-RTT，提升首屏速度
Nginx 层三步精准控制
Nginx 不会自动丢弃 Early Data，必须显式配置才能把风险拦在入口：
-
用 limit_except 限定方法：在对应 location 块中写
limit_except GET HEAD { deny all; }，确保只有安全方法能走0-RTT -
透传 Early-Data 标识：添加
proxy_set_header Early-Data $ssl_early_data;，让后端清楚知道该请求是否来自0-RTT -
按路径隔离策略：防护逻辑必须写在 location 块内，例如
location /api/v1/order单独收紧，不能放在 server 或 http 全局块里
后端必须校验并响应425状态码
收到带 Early-Data: 1 请求头的写操作，后端不能直接处理，必须主动拒绝：
- 检测到
Early-Data: 1且请求方法为 POST/PUT 等，立即返回HTTP 425 Too Early - 客户端收到 425 后，会自动降级为完整 1-RTT 握手并重发，这是 RFC 8470 明确定义的行为
- 若业务场景极特殊（如超低延迟交易），需叠加应用层防护：一次性 token + 时间戳（窗口 ≤ 5 秒）+ 请求指纹（body hash + IP + UA 哈希），三者缺一不可
CDN 或边缘节点增强校验（可选但推荐）
在 CDN 层做前置过滤，能更早拦截恶意重放流量，减轻源站压力：
- 在 ticket data 中扩展自定义字段（如时间戳+随机数），由管理机统一校验有效性
- 对疑似重放的 Early Data 请求，主动退化为 1-RTT，不转发至源站
- 结合请求频次限流（如同一 ticket 5 秒内仅允许 1 次写操作），从行为维度补充防护
