协议重放失败排查调试思路
协议重放失败排查：别反复补 header，先把失败归因分层
协议重放失败时，很多人最容易做的一件事，就是在 header、cookie、query 参数里来回微调。问题是，如果你没有先把失败归因分层，这种补法往往只是在原地打转。
先说结论：重放失败不是一个问题，而是一组不同层级的问题
最常见的失败层面通常包括：
- 会话态不对
- 签名链不对
- 时间窗/nonce 不对
- 设备态不对
- 请求顺序不对
- 参数边界不对
如果不先把失败归因分层，你就会把所有问题都误处理成“可能少了个 header”。
第一层：会话态
先看 token、cookie、登录态、前置接口返回值是不是完整一致。很多请求不是单独成立，而是依赖前序状态。
第二层：签名链
如果服务端在校验签名，那你真正要确认的通常不是“header 像不像”，而是：
- 输入字段是否完整
- 排序拼接是否一致
- 时间/随机量是否参与
- 最终签名是不是在正确时机生成
第三层：时间窗与随机性
很多重放失败根本不是签名算法错，而是请求过期、nonce 重复、时间窗不在允许范围内。
第四层：设备态与环境态
一些接口会把设备指纹、安装状态、运行上下文一起算进合法性。你如果只复刻网络包，可能还差一整个设备态。
第五层：请求顺序
有些接口不是“单点请求”，而是一个序列中的一步。你跳过前置动作或顺序不一致，也会导致重放失败。
最容易犯的错误
- 一直补 header，不验证签名链
- 只抓一次成功样本，不做多组对照
- 忽略前置请求和状态传递
- 失败后继续在同一层微调，不换归因视角
我更推荐的排查顺序
- 先确认会话态
- 再确认签名链
- 再排时间窗/nonce
- 再排设备态和请求顺序
这套顺序的好处是：你不会把所有失败都当成一类问题来修。
结尾
协议重放失败最折磨人的地方，不是“哪里都像有问题”，而是你如果不分层，就会一直在最表面的字段上微调。把失败拆成会话、签名、时间、设备、顺序几个层面，路径就会一下子清楚很多。