Claude 返回 401 时，原因总是以下五种之一：标头错误、端点所需的密钥类型错误、环境变量格式错误、密钥已撤销，或该密钥对应的 base URL 错误。运行下面的诊断，不到一分钟就能找到具体原因。
错误
响应（HTTP 401）
{
"type": "error",
"error": {
"type": "authentication_error",
"message": "invalid x-api-key"
}
}原因和解决方法一览
| 原因 | 解决方法 |
|---|---|
| 端点使用了错误的标头 | Anthropic 原生 API 需要 x-api-key + anthropic-version；OpenAI 兼容端点需要 Authorization: Bearer。 |
| 密钥与端点不匹配 | sk-ant-… 密钥只能用于 api.anthropic.com；网关密钥（例如 sk-kn-…）只能用于其自己的网关 URL。 |
| 环境变量中混入空白字符或引号 | 重新导出时去掉引号和换行；打印 len(key)，以捕获复制粘贴带入的尾随 \n。 |
| 密钥已撤销或工作区已禁用 | 在控制台生成新密钥，并在密钥管理器中轮换。 |
使用原始 curl 重现（排除 SDK 影响）
如果 curl 可以工作而应用不行，问题在环境变量传递，而不是密钥：
diagnose.sh
# Native Anthropic wire (works on api.anthropic.com and Kunavo /v1/messages)
curl -s https://api.kunavo.com/v1/messages \
-H "x-api-key: $KUNAVO_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'
# OpenAI-compatible wire (Bearer header instead)
curl -s https://api.kunavo.com/v1/chat/completions \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'
# Check the key isn't carrying whitespace
python3 -c "import os; k=os.environ['KUNAVO_API_KEY']; print(repr(k[:12]), len(k))"将密钥前缀与 base URL 匹配
sk-ant-… → api.anthropic.com。sk-kn-… → api.kunavo.com/v1。将网关密钥发送给 Anthropic（或反过来）一定会返回 401——错误消息从不写明“主机错误”，所以这个问题很容易被忽略。
如果密钥曾接触过代码仓库或日志，请轮换
如果密钥正确却仍被拒绝，应假设它已被撤销（自动扫描器会快速撤销泄露的密钥）。生成新密钥并存入密钥管理器，不要存放在可能被提交的 .env 文件中。
如果你通过 Kunavo 调用
Kunavo 密钥（sk-kn-…）可在每个端点的任一标头中进行认证——既可以使用 OpenAI SDK 发送的 Authorization: Bearer，也可以使用 Anthropic SDK 使用的 x-api-key。因此无论使用哪种 SDK，只需更改 base URL。密钥可在控制台中即时创建和撤销。 密钥通过认证后，其计费费率位于 Anthropic Claude API 价格列表.
常见问题
为什么我的密钥在 curl 中有效，在应用中却无效？
几乎总是环境变量传递问题：复制粘贴带入尾随换行、值中包含引号、变量未导出到进程，或生产环境加载了不同的环境变量。在失败的进程内部打印密钥的 repr 和长度。
可以在 OpenAI 兼容网关上使用 Anthropic Console 密钥吗？
不可以。每项服务只认证其自己的密钥：sk-ant 密钥属于 api.anthropic.com，网关密钥属于网关。应从你所调用的 base URL 获取对应的密钥。