425 是什么
425 Too Early 表示服务器拒绝处理「过早到达」的请求（RFC 8470 §5.2）：客户端在 TLS 1.3 握手中用 0-RTT（early data）提前发送了应用数据，服务器出于重放风险不愿处理非幂等请求。它是保护动作，避免被截获的 0-RTT 数据被重放执行，造成重复下单或重复提交。
基本信息
| 名称 | 425 Too Early |
|---|---|
| 类别 | 4xx |
| 规范 | RFC 8470 §5.2 |
| 关联技术 | TLS 1.3 的 0-RTT early data（RFC 8446） |
| 典型触发 | 非幂等请求（POST、PUT）走 0-RTT |
| 推荐处理 | 客户端等握手完成后按普通请求重发 |
典型使用场景
- 上线 TLS 1.3 与 0-RTT 优化后出现 425：确认哪些方法的请求走了 early data
- 支付与下单类接口的防重放：服务端对非幂等请求一律拒绝 0-RTT
- 抓包分析：观察 ClientHello 之后是否紧跟应用数据
- 客户端库配置：禁用或收紧 0-RTT 的适用范围
- 监控口径：把 425 单列，避免与业务错误混淆
- 安全评审：评估开启 0-RTT 带来的重放风险面
观察与规避
观察与规避
# 观察 TLS 1.3 与 early data 相关协商结果
openssl s_client -connect example.com:443 -tls1_3 -early_data </dev/null 2>&1 | grep -i -E 'early|rejected'
# 服务端返回 425 时，客户端等握手完成后按普通请求重发即可
curl -sv https://api.example.com/order -X POST -d @order.json 2>&1 | grep -E '< HTTP|handshake'0-RTT 的取舍
| 选项 | 收益 | 风险 |
|---|---|---|
| 0-RTT | 省一次往返，弱网首包更快 | 数据可被重放，非幂等请求危险 |
| 1-RTT | 握手完成后才发送 | 不可重放，但多一个往返 |
| 服务端策略 | 按方法与路径决定是否接受 | 需要谨慎维护白名单 |
| 客户端策略 | 只对幂等方法启用 | 需要配置与验证 |
425 是「稍后重试」信号而不是失败：客户端等握手完成重发即可，业务侧通常无需提示用户。
收到 425 说明链路确实使用了 TLS 1.3 early data；若业务不容许重放风险，应在服务端统一禁用 0-RTT。
0-RTT 的性能收益在弱网与首次连接场景比较明显，但它只对幂等请求有意义，不要为了指标牺牲正确性。
监控里把 425 与普通 4xx 混在一起看，会掩盖 TLS 层配置问题，建议单独统计。