核心问题是新旧链路签名输入源不一致：时间戳被覆盖、请求头顺序/大小写变化、参数编码差异、body被网关格式化、关键header被静默修改，以及密钥或算法跨环境错配。
流量切换后API接口验签失败，核心问题在于新旧链路中签名计算环境不一致。不是签名逻辑本身错了，而是参与签名的要素在切换过程中被隐性改变——比如时间戳、请求头顺序、参数编码方式、网关透传字段等。排查要从“签名输入源”出发，而不是只盯签名结果。
确认是否真为验签失败，而非其他401原因
先排除干扰项：流量切换后出现401，未必是验签失败。需结合响应头和错误信息判断：
- 若返回头含 X-Ca-Error-Message: StringToSign mismatch 或类似提示，才是明确的验签失败；
- 若返回 "AUTHSTRATEGY_NOT_FOUND" 或 "无效的应用"，说明鉴权模式或AppID未适配新链路；
- 若响应体为 {"code":401,"message":"TOKEN错误"}，实际是OAuth Token未同步或失效，非验签问题。
比对新旧链路的StringToSign输入项
验签失败的本质是服务端与客户端算出的 StringToSign 不一致。流量切换常导致以下输入项变化：
- 时间戳（timestamp）：新链路网关可能使用自身系统时间，而非客户端传入的时间；检查 X-Tsign-Open-Ca-Timestamp 是否被覆盖或丢弃；
- 请求头顺序与大小写：部分网关（如Kong、阿里云API网关）会标准化Header名（如转为小写），而签名逻辑依赖原始大小写或顺序；
- 参数编码方式：旧链路可能自动URL编码，新链路未编码或双重编码；特别注意空格、中文、&、= 等字符；
- Body内容是否被修改：新链路代理可能格式化JSON（重排键序、删空格）、或对流式body做缓冲处理，导致签名时body与服务端收到的不一致。
检查网关层是否静默修改或过滤关键字段
流量切到新网关后，常见静默行为会破坏签名完整性：
- 网关默认移除或重写 Authorization、X-Tsign-Open-Ca-Signature 等自定义Header；
- 对 Content-Type 做强制标准化（如将 application/json;charset=utf-8 改为 application/json）；
- 开启gzip压缩但未在签名时纳入压缩标识；
- 添加/删除X-Forwarded-*类Header，而签名逻辑未排除它们（或错误地包含了它们）。
验证密钥与算法是否跨环境一致
看似基础，却极易被忽略：
- 确认新链路调用使用的 SecretKey 是该环境对应AppID的密钥，不是沿用旧环境密钥；
- 检查签名算法是否变更：例如旧链路用 HMAC-SHA256，新网关文档要求 HMAC-SHA1；
- 确认签名时使用的 AppKey 与网关配置的 App ID 完全一致（包括大小写、前缀、沙箱/正式标识）；
- 若使用动态密钥（如临时Token派生密钥），确认新链路中密钥派生逻辑未因上下文丢失而失效。
