DynamoDB IncompleteSignatureException

TL;DR — 请求的 AWS Signature Version 4 签名不完整，或者不符合 AWS 标准，所以 DynamoDB 在认证之前就拒绝了它。如果你用的是 AWS SDK，签名是自动的——这几乎总是意味着请求是手工构造的，或者某个代理/网关在签名之后弄坏了 Authorization 头。让 SDK 来签名，并确保传输途中没有东西重写请求。

含义

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS 用 SigV4 对每个请求签名。这个异常意味着签名存在，但格式有误或缺少必需的组成部分——一个糟糕的 Authorization 头、一个缺失的签名头，或者规范请求（canonical request）对不上。它是 HTTP 400，发生在客户端，且原样不可重试：签名必须先改对。

为什么会发生

手写签名——你在自己（而不是通过 SDK）构造 SigV4 签名，而规范请求、signed-headers 列表或 Authorization 头写错了。
Authorization 头格式有误——文档记载的触发条件是：头为空、缺少 Credential 或 Signature 参数、头没有以算法名（AWS4-HMAC-SHA256）开头，或者某个 key=value 对少了等号。
某个代理或 API 网关重写了请求——在 SDK 签名之后改动 Authorization 头（或其他被签名的部分），会让 AWS 收到的头与你发出的那个不同。
手工编辑过头部——签名之后增删头部、或者重排查询字符串，都会破坏规范请求。

如何修复

使用官方 AWS SDK，让它来签名。这些 SDK 已经替你正确实现了 SigV4——对几乎每一次发生来说，修复办法就是别再手工签名了。
签名之后不要再改动请求——如果前面挡着一个代理/网关，要确保它不会添加、丢弃或重排头部，也不会改动 body/路径。在真正发出请求的那一端做签名。
检查 Authorization 头在传输途中有没有被改动——AWS 记载的诊断办法：对你发出的那个头计算 SHA-256 哈希、做 Base64 编码，再与某些 IncompleteSignatureException 消息里附带的哈希比对。如果不同，说明你的客户端与 AWS 之间有东西改动了这个头。
如果你必须手工签名，就严格遵循 AWS SigV4 的签名流程——规范请求、待签字符串、签名密钥推导，以及 Authorization 头（算法、Credential=、SignedHeaders=、Signature=）全都必须对上。拿一个已知正确的 SDK 请求来核对。

密钥错误或被截断是另一种故障：它产生的是一个_完整_但对不上的签名，浮现出来是“signature we calculated does not match”，而不是这个错误。同样地，机器时钟偏移浮现出来是 Signature expired，而不是签名不完整。

DynoTable + Local

DynoTable使用AWS SDK签名路径——没有手工构建的SigV4——所以在正常使用中不会出现这个错误类。如果你的应用程序在 DynoTable 工作时命中它，请比较配置文件：Settings → Profiles → Test Connection 与你的应用程序加载的相同键。对于本地，具有端点 http://localhost:8000 的配置文件上的虚拟凭据完全绕过签名。参见连接 AWS和安装。凭据解析后，在 Query Builder 中运行冒烟测试查询。

来源

Error handling with DynamoDB — IncompleteSignatureException（2026-07-13 验证）
Troubleshoot Signature Version 4 signing（2026-07-13 验证）

常见问题

什么原因导致 IncompleteSignatureException？ 请求中的 AWS SigV4 签名格式错误或缺少所需部分 - 空的或格式错误的 Authorization 标头、缺少 Credential 或 Signature 参数，或者不带等号的键=值对。使用 AWS SDK 签名是自动的，因此它通常意味着手动构建的签名或在签名后更改请求的代理。

这与 UnrecognizedClientException 有什么不同？ IncompleteSignatureException 意味着签名本身格式错误。 UnrecognizedClientException（“安全令牌无效”）意味着签名格式正确，但其背后的凭据未被接受。

复现方法

发送一个存在但不可解析为 SigV4 的 Authorization 标头：

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

实际输出：

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400

尾随的 Base64 字符串是你自己的标头的哈希值，因此它在每个请求上都不同 - 不匹配。该消息告诉你的是结构性的：AWS可以读取算法，但不能读取其后面的Credential=/SignedHeaders=/Signature=对。这表明标头是如何组装的，这就是为什么标头几乎总是来自手动签名而不是来自 SDK。

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

2026-07-26 针对 us-east-1 的实时 DynamoDB 服务复现——上方输出为原样照录。