直接答案
401 首先是认证链问题：确认请求发往哪个服务、服务期待哪种请求头、客户端实际从哪里读取凭据。
这篇内容解决什么问题
解决 Codex、Claude Code、OpenAI SDK 与 Anthropic 兼容 API 返回的 401、invalid_api_key 和 authentication_error。
先确认症状与影响范围
请求返回 401 Unauthorized、invalid_api_key 或 authentication_error。如果模型 ID、请求体和网络都未改变，而更换凭据后结果变化，问题集中在认证链。
浏览器控制台、SDK 和 CLI 可能从不同位置取 Key；终端中存在变量不代表当前进程一定使用它，也不代表请求头名称符合网关要求。
- 确认失败请求的主机名和协议，防止 Key 被发往错误服务。
- 确认服务要求
Authorization: Bearer还是x-api-key。 - 确认 Key 未过期、未撤销、无前后空格，并属于当前账号或项目。
常见原因与责任边界
401 可能来自终端环境、客户端配置、反向代理或上游模型服务。必须先确认哪一层生成响应，不能仅凭错误文案认定 Key 本身失效。
- Key 被撤销、复制不完整、包含换行或使用了错误环境的凭据。
- Bearer token 放进
x-api-key，或 Anthropic API Key 被放进 Authorization。 - Base URL 指向另一套服务，客户端把正确 Key 发给了错误主机。
- 旧会话、IDE 或守护进程仍缓存轮换前的环境变量。
按层执行最小诊断
先检查客户端自己的登录状态和最终 Base URL，再用同一主机执行不泄露 Key 的最小认证请求。不要打印环境变量值，只确认变量是否存在以及长度是否合理。
Claude Code Gateway 需特别区分 ANTHROPIC_AUTH_TOKEN 与 ANTHROPIC_API_KEY；Codex 需确认 provider 使用的凭据环境变量和 CODEX_HOME。
- 01确认目标主机在不输出查询参数和请求头的前提下记录最终 Base URL。
- 02确认凭据来源检查 CLI 登录状态、环境变量名称和配置作用域，不显示值。
- 03确认请求头按目标协议选择 Bearer 或 x-api-key，不同时发送多套凭据。
- 04最小复现使用模型列表或最小消息请求确认认证是否独立成功。
test -n "$API_KEY" && echo 'API_KEY is set' || echo 'API_KEY is missing'
codex login status 2>/dev/null || true
codenodex keys 2>/dev/null || true
# Claude Code 会话中另行运行 /status，切勿打印 token。
针对根因完成修复
确认凭据确实失效后，在服务端撤销旧 Key 并创建新 Key，再重启读取环境变量的 CLI、IDE 或后台进程。请求头不匹配时只修改认证映射，不要同时更换模型和 Base URL。
- 01撤销泄露 Key只要真实值进入聊天、日志或版本库，就先在服务端撤销。
- 02更新正确入口将新 Key 写入受支持的 Secret 或 CLI 凭据存储。
- 03重启进程关闭旧会话与 IDE 后重新加载环境，避免继续使用缓存值。
- 04单点验证先验证认证，再恢复原模型和完整任务。
验证修复而不是只看一次成功
验证应覆盖新 Key 成功、旧 Key 已拒绝、客户端显示预期 Base URL 三件事。仅看到一次 200 不能证明泄露凭据已经失效。
- 新 Key 的最小请求成功且返回预期服务的 request ID。
- 旧 Key 已撤销，不能继续调用。
- Codex、Claude Code 或 SDK 均从预期凭据来源读取。
安全边界与升级证据
不要在 curl 命令历史、截图、工单或 Git 仓库中放真实 Key。诊断材料只说明 Key 前缀是否符合格式、变量是否存在和服务端返回的 request ID。
- 使用 Secret 管理、标准输入或客户端凭据存储。
- 轮换后同步清理 CI、IDE、shell profile 和后台服务中的旧值。
- 不要通过关闭认证或共享管理员 Key 绕过 401。
官方来源与核验范围
本文以协议规范和客户端官方文档为事实依据。错误文案、重试头和配置字段可能随服务或客户端版本变化；执行前请核对来源，并对日志与请求样例脱敏。
查看技术核验方法