负载均衡导致API签名验证失败的主因是其篡改了签名依赖的原始请求要素，最常见为Host头被重写；需配置proxy_set_header Host $host、透传关键头、统一协议上下文，并通过比对服务端返回的StringToSign定位差异。
负载均衡接入后出现API签名验证报错（如 SignatureDoesNotMatch、AuthFailure.SignatureFailure 或 401），通常不是后端服务本身的问题，而是负载均衡器在转发请求过程中**无意篡改了签名计算所依赖的原始请求要素**。核心矛盾在于：签名是基于原始请求严格生成的，而代理层若修改了关键字段（如 Host、协议头、请求体、时间戳上下文等），服务端验签必然失败。
重点查 Host 头是否被重写
这是最常见、最高发的根因。MinIO、微信支付、阿里云等多数签名体系都把 Host 头纳入 StringToSign 计算。Nginx 默认会重写 Host 为 upstream 的地址（如 10.0.0.1:9000），导致客户端签的名和服务端算的 StringToSign 不一致。
- 在 Nginx 配置中显式透传原始 Host：
proxy_set_header Host $host;（注意不是$http_host，后者可能带端口） - 禁用自动 Host 重写：
proxy_redirect off; - 验证方式：在后端日志或调试接口中打印收到的
Host头，对比客户端发出的是否一致
确认协议头与请求上下文未被污染
签名常依赖 X-Forwarded-Proto、Content-Type、Date 或自定义认证头（如 Authorization）。负载均衡若改写、丢弃或大小写不一致，都会导致验签失败。
- 确保关键头原样透传：
proxy_pass_request_headers on;proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header Content-Type $content_type; - 避免 Nginx 自动添加或覆盖头（例如某些版本会强制加
Connection: close） - HTTPS 场景下特别注意：若负载均衡终止 HTTPS 后以 HTTP 转发给后端，但签名逻辑仍按 HTTPS 构造
StringToSign，就会失败 → 必须统一协议上下文
比对服务端返回的 StringToSign
多数网关（如阿里云 API 网关、腾讯云 APIM）会在签名失败响应头中返回服务端实际计算出的 StringToSign（如 X-Ca-Error-Message）。这是最直接的诊断依据。
- 用
curl -v或抓包工具捕获完整响应，提取该 header 值 - 在客户端复现相同请求（相同参数、时间、Host、头、body），本地重新生成
StringToSign - 逐字符比对（注意忽略换行符、空格、编码差异）；不一致处即问题源头
绕过负载均衡直连后端做基线验证
快速判断问题是出在负载均衡配置，还是后端或客户端逻辑本身。
- 用
curl -H "Host: your-api-domain.com" http://<backend-ip>:<port>/path</port></backend-ip>模拟真实请求 - 若直连成功，说明签名逻辑和后端无误，问题 100% 在负载均衡转发链路
- 若直连也失败，则回归客户端签名实现：检查私钥是否正确、参数排序是否 ASCII 升序、AppSecret 是否拼接在末尾、编码是否统一 UTF-8
