线上偶发验签失败：网关吃前缀 + 时间戳单位

🐮LittleID264 · 1 小时前

线上收款偶发失败，十笔错一笔。支付方后台显示「通知失败，已重试 5 次」，最后钱退回去了；我这边日志只有一行 signature mismatch。查了三天，根因是两个问题叠在一起：网关把回调路径前缀吃掉了，验签代码又把时间戳解析后重新拼回签名原文。
现象
[WARN] callback verify failed: signature mismatch orderNo=PO2026102300xx timestamp=1730xxxxxxx sign=V5x...[INFO] retry 1/5 ... retry 5/5 failed, give up三个特征：失败不是全量，约 1/10 ；本地用同一套密钥、同一份报文重算签名能过；把生产抓包原文放进测试环境回放也能过。
先把能查的手边项排一遍：三处密钥比对一致；拼接规则按文档排序、空值处理、URL 编码与抓包逐字节比对一致； NTP 偏差 200ms 内； nonce 在 Redis 写入读回正常。这些全对，线上照样失败，说明问题不在你正在看的这一层，得跳到链路两头去看。
第一步：先看请求有没有打到路由
应用侧日志搜订单号，0 条；网关访问日志同一时间窗里，发往 /pay/callback 的请求全是 404 。到这里就该停手：404 不是签名问题，验签代码一次都没执行。原因是网关转发时把 /pay 前缀吃掉了，proxy_pass 末尾少一个斜杠，location 匹配的那段被整个替换，打到后端的路径少了前缀。把末尾斜杠和 location 对齐、保留前缀就好了。
第二步：直接打自己的回调地址
用 curl POST 自己的回调 URL ，判据只有一条：返回的必须是应用层响应（比如 {"code":"PARAM_ERROR"}），不是网关的 404/502 HTML 页面。修好前缀后，失败率从 1/10 掉到约 1/3 ，说明还有第二个问题在挡着。
第三步：把参与签名的原文打出来比对
不要反复重算签名，先把原文和字段长度落日志：
log.Info("verify raw", "raw", rawForSign, "ts", req.Timestamp, "ts_len", len(strconv.FormatInt(req.Timestamp, 10)))日志出来 ts_len=13，是毫秒。而代码里是这么拼的：
// 错：先解析再格式化，原文就变了ts := time.Unix(req.Timestamp/1000, 0).Format("2006-01-02 15:04:05")rawForSign := fmt.Sprintf("...&timestamp=%s", ts)对方发来 13 位毫秒，我方 /1000 之后格式化成秒级字符串再拼回原文，差 3 位，签名必然不匹配；时间窗校验反而是对的，所以日志里只看到签名无效，看不到过期。正确做法一句话：签名原文只用对方发来的原始字符串，任何字段都不解析、不重新格式化。
修复就三件事：时间戳单位改成显式配置，并对 10 位和 13 位做归一化；单位不匹配时打 WARN ，不要静默失败；验签失败日志按 timestamp 、sign 、nonce 分步骤输出，带脱敏样本。
为什么偶发
灰度期间一半实例新配置、一半旧配置。落到旧实例：前缀被吃，直接 404 ；落到另一台旧实例：前缀对、但时间戳被重新格式化，验签失败。两个问题叠加，观感就是十笔错一笔。偶发不是网络抖动，是部分机器配置不一致的指纹。
怎么避免
这类问题最难的地方不在修，而在你一开始就怀疑错了方向。接入文档里把时间戳单位写死（ 13 位毫秒 / 10 位秒），验签日志常打 ts_len，签名原文只取原始字符串，灰度时挂一条验签成功率指标，低于 99% 自动回滚。

⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉

线上偶发验签失败：网关吃前缀 + 时间戳单位

回复

快捷访问

附加功能

关于我们

关注我们