Webhook直连应用时验签成功，一放到反向代理或Serverless网关后就提示签名不匹配。多数签名算法没有“代理感知”，真正变化的是应用拿到的待签字节：请求体被解压、字符集处理，或框架先解析JSON再重新序列化。
签名通常覆盖哪些数据
不同平台可能签原始请求体，也可能把时间戳、请求路径、方法或事件ID一起加入。算法可能是HMAC，也可能是公钥签名。必须以发送方当前官方规范为准，不能看到一个X-Signature头就套用通用示例。
为什么原始字节如此重要
下面两个JSON对象语义相同，但字节不同：字段顺序、空格、换行、Unicode转义和数字格式都会改变摘要。框架把body解析成对象后再序列化，往往无法还原发送方签名的原始内容。
代理可能改动哪些内容
| 变化 | 可能影响 |
|---|---|
| 自动解压gzip | 签名若针对压缩字节，输入发生变化 |
| 字符集转码 | 同一文字的字节序列改变 |
| 请求体检查与重写 | 安全设备可能规范化内容 |
| 分块转Content-Length | 通常不改body语义，但规范可能包含其他字段 |
先对比入口和应用获取的请求体哈希，不要在日志中输出完整敏感内容。
框架中要先验签再解析
为Webhook路由保留原始body缓冲，读取签名和时间戳头，按规范计算并使用常量时间比较；验证通过后再解析JSON。请求体仍要有大小上限，避免为了保留原始数据让攻击者占用大量内存。
时间戳如何阻止旧请求
签名头常包含发送时间。接收方允许一个合理偏差窗口，超出就拒绝，即使HMAC正确。服务器时钟必须可靠，并记录使用的UTC时间。窗口过大削弱防重放，过小又会受网络延迟和排队影响。
事件ID与幂等
同一个Webhook可能因超时被合法重发。以平台提供的事件ID建立去重记录，并让业务处理幂等。不要只按请求体哈希永久去重，因为两个独立事件可能内容相同；去重保存期限要覆盖平台重试窗口。
快速响应，异步处理
验签和基本校验通过后，将事件安全写入队列或事务存储，再快速返回成功。耗时业务在后台处理。若接收端在完成全部业务后才响应，发送方容易超时重试，造成同一事件并发执行。
密钥如何轮换
支持短期同时验证新旧两个密钥，先部署验证能力，再切换发送方，最后撤销旧密钥。日志只记录密钥版本或标识，不能记录秘密本身。怀疑泄露时要轮换，并审查历史异常回调。
来源IP能代替验签吗
不能。发送方IP可能变化、共享或经过云平台，来源白名单只能作为补充。签名验证、TLS、事件去重和最小业务权限仍然需要。固定出口与白名单的边界可参考NAT网关和代理固定出口选型。
安全排查顺序
- 确认平台签名版本、算法和精确拼接规则；
- 保存原始请求体哈希、时间戳、事件ID和签名版本；
- 对比代理前后body是否解压、转码或重写；
- 确保验签发生在JSON解析之前，并限制大小；
- 验证时间窗口、常量时间比较和密钥轮换；
- 模拟超时重试，确认事件只产生一次业务结果。
失败响应也不能泄露调试细节
验签失败时返回统一的4xx和请求ID即可，不要把预期签名、计算结果、密钥标识细节或原始请求体回显给发送方。内部日志可记录算法版本、时间偏差、body哈希和拒绝阶段，并限制访问与保留期限。这样既能排查，也不会给攻击者提供逐步校准伪造请求的反馈。
队列写入与成功响应的边界
只有事件已可靠写入队列或事务存储后，才适合返回成功。如果先响应再入队，进程崩溃会造成发送方认为成功而事件丢失；如果完成全部业务才响应，又容易触发重试。接收记录应包含事件ID、接收时间、签名版本和处理状态，支持失败重放但仍保持业务幂等。
结论
Webhook验签失败的关键不是“代理是否存在”，而是签名输入是否保持为规范要求的原始字节。保留原始body、校验时间戳、实施事件幂等和密钥轮换，才能同时解决误拒绝与重放风险。
