验证 TLS 1.3 0-RTT 防重放需三层实测：一查协议能力（openssl/Wireshark/浏览器确认 TLSv1.3 与 Early Data）；二验 Nginx 拦截（limit_except 拒非幂等请求、$ssl_early_data 透传一致）；三测后端闭环（Early-Data:1 请求须返 425 或严格校验 nonce+时间窗+指纹），任一环失效即成安全缺口。
要验证 Nginx 下 TLS 1.3 0-RTT 的防重放机制是否真正生效，不能只看“连接成功”，而要分三层实测：协议能力、Nginx 层拦截逻辑、后端协同响应。每层都需可观察、可复现、可证伪。
一、确认 TLS 1.3 和 0-RTT 协议能力已启用
这是前提，否则后续所有防护都无从谈起：
- 用 openssl s_client 检查握手是否走 TLS 1.3 并携带 Early Data：
openssl s_client -connect your-domain.com:443 -tls1_3 -ign_eof -debug 2>&1 | grep -i "early\|protocol"
若输出含Early data is supported或Protocol : TLSv1.3，说明基础就绪 - 浏览器验证：Chrome/Firefox 访问站点 → 开发者工具 → Security 标签页 → 查看“Connection”字段是否显示 TLS 1.3 且 “Early data” 为 Yes
- 抓包验证（Wireshark）：过滤
tls.handshake.type == 1（ClientHello），检查扩展字段中是否存在early_data，且后续帧中紧随 ClientHello 出现application_data—— 这是 0-RTT 数据发出的直接证据
二、验证 Nginx 层对非幂等请求的拦截是否生效
Nginx 必须在 TLS 解密后、转发前就拒绝带副作用的 0-RTT 请求，不能依赖后端兜底：
- 构造一个明确走 0-RTT 的 POST 请求（如登录接口）：
curl -X POST https://your-domain.com/api/v1/login \--http2 -k --data '{"user":"a","pass":"b"}' -v 2>&1 | grep "HTTP/"
若返回 405 Method Not Allowed 或 403 Forbidden（而非 200/422），说明limit_except GET HEAD { deny all; }已在对应 location 内生效 - 检查 Nginx 是否正确透传标识：
在后端日志或调试接口中打印Early-Data请求头值；同时在 Nginx access_log 中添加$ssl_early_data变量，对比两者是否一致（应同为1或空） - 测试 GET 路径是否仍畅通：
curl -I --http2 -k https://your-domain.com/status应返回 200，且 Wireshark 中可见 Early Data 发送 —— 验证“仅读操作放行”策略未误伤
三、验证后端对 Early-Data: 1 的响应逻辑是否闭环
Nginx 不做业务判断，但后端收到 Early-Data: 1 后必须拒绝写操作并给出明确语义响应：
- 对 POST/PUT/DELETE 接口发起两次完全相同的 0-RTT 请求（可用 curl + --repeat 或脚本模拟）：
首次应返回 425 Too Early（RFC 8470 标准码），客户端据此重发 1-RTT 请求
第二次（重放）若仍返回 425 或 200，则说明后端未校验该头，存在风险 - 若业务允许极少数 0-RTT 写（如投票），需验证三要素是否全启用：
• 请求中是否含有效X-Request-Nonce和X-Request-Timestamp
• 后端是否用 Redis 执行SET key "1" EX 5 NX（5 秒窗口）
• 请求指纹是否包含 body hash + IP + UA 的组合哈希（非单一字段） - 检查 CSRF Token 流程是否同步受控：
带X-CSRF-Token的 0-RTT POST 请求，若 Token 已被后端销毁，应返回 403；若仍通过，说明 Token 清除逻辑未与 Early-Data 判断联动
四、安全边界验证：重放攻击能否真实触发
用最小成本模拟攻击路径，检验防线是否断裂：
- 用 Wireshark 截获一次成功的 0-RTT POST 请求（含完整 body 和 headers）
导出该 HTTP 流 → 编辑为 curl 命令（保留所有头、禁用自动重定向）→ 立即重放 3 次
理想结果：全部返回 425 或 403；若某次返回 200 或状态变更（如订单创建成功两次），即防线失效 - 更换 IP 或 UA 重放同一请求：
若后端仅校验 Nonce + 时间戳，未绑定 IP/UA，可能绕过；此时应触发失败，证明指纹校验生效 - 延迟重放（超过 5 秒）：
记录请求时间戳，等待 6 秒后再发 —— 应被时间窗拦截，返回 400 或 403
测试不是一次性动作，而是每次配置变更后必做的回归项。重点盯住三个信号点：协议协商成功、Nginx 拒绝非幂等方法、后端返回 425 或严格校验。漏掉任一环，0-RTT 就从性能优化变成安全缺口。
