错误排查

OpenAI API 401 invalid_api_key 怎么排查

从 Authorization 请求头、环境变量、Base URL、Key 所属平台和进程配置逐项定位 OpenAI Compatible API 的 401 Unauthorized 与 invalid_api_key,避免无效重试和密钥泄露。

更新于 2026-07-18已核对 2026-07-18预计阅读 9 分钟适用于 OpenAI SDK、curl、Cursor、Dify、OpenWebUI 与 OpenAI Compatible API
配置字段已按公开文档核对;模型、价格和可用能力会变化,请以控制台与接口实时返回为准。
所属专题:OpenAI Compatible API 接入与排错中心

401 Unauthorizedinvalid_api_key 的核心含义是:当前请求携带的认证信息没有被目标接口接受。它通常不是网络波动,也不应该靠重试解决。

30 秒判断问题在哪

先绕开 Cursor、Dify 等客户端,直接测试模型列表:

curl -i https://www.aifast.club/v1/models \
  -H "Authorization: Bearer $AIFAST_API_KEY"

根据结果分流:

结果 优先检查
curl 也返回 401 Key 内容、账号状态、请求头和目标平台
curl 成功,客户端返回 401 客户端读取的环境变量、配置优先级和重复 Bearer
一个域名成功,另一个域名 401 Key 与 Base URL 不属于同一平台
偶尔成功、偶尔 401 多实例配置不一致、旧 Key 未替换或请求实际走了不同入口

不要把完整 Key 粘贴到在线问答、Issue、日志或截图中。排错时只保留前后各 3 至 4 位用于区分不同 Key。

按顺序检查六个位置

1. Key 和 Base URL 是否属于同一平台

第三方平台创建的 Key 不能直接发给官方 OpenAI 地址,官方 OpenAI Key 也不应默认发给其他网关。先确认这两个配置来自同一个服务:

Base URL: https://www.aifast.club/v1
API Key:  在 AI快站控制台创建的独立 Key

如果正在从其他平台迁移,必须同时替换 Base URL 和 Key,不能只改其中一个。

2. Authorization 请求头是否正确

OpenAI Compatible 接口通常使用:

Authorization: Bearer sk-***

常见错误包括:

  • 写成 Authentication 或其他请求头;
  • 遗漏 Bearer 与 Key 之间的空格;
  • 客户端已经自动加 Bearer,配置值里又写了一次;
  • Key 前后带有引号、换行或复制时混入空格;
  • 反向代理没有转发 Authorization 请求头。

3. 当前进程是否真的读到了新环境变量

修改 shell 配置文件不等于已经更新正在运行的程序。先只确认变量是否存在和长度,不要输出完整内容:

test -n "$AIFAST_API_KEY" && echo "Key 已加载,长度 ${#AIFAST_API_KEY}" || echo "Key 未加载"

IDE、桌面客户端、Docker 容器和系统服务可能不会继承当前终端变量。修改后应重启对应进程,并在它自己的运行环境中检查。

4. 是否存在多套配置覆盖

检查项目 .env、用户级配置、工作区配置和启动参数。典型现象是:终端 curl 使用新 Key,但客户端仍从旧配置文件读取已撤销的 Key。

排查时一次只保留一个认证来源。确认成功后,再恢复需要的配置层级。

5. Key 是否仍然可用

确认 Key 没有被删除、禁用或轮换,账号状态也正常。不要用生产 Key 做公开排错;应创建权限和余额都受控的测试 Key。

6. 最终请求是否发到了预期域名

客户端界面里的 Base URL 不一定等于最终请求地址。通过客户端诊断日志或服务端请求记录确认:

  • 最终主机名;
  • 最终路径;
  • 是否经过额外代理;
  • 响应正文中的错误类型与请求 ID。

可以先用 Base URL 在线检查器 检查地址拼接,再回到客户端配置。

Python SDK 最小验证

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://www.aifast.club/v1",
    api_key=os.environ["AIFAST_API_KEY"],
    max_retries=0,
)

models = client.models.list()
print("认证成功,返回模型数:", len(models.data))

排查 401 时暂时关闭自动重试。认证配置不变,重发同一请求不会自行恢复。

不要用这三种错误方法

  1. 连续重试 401。 只会放大日志和请求量,不会修复认证。
  2. 把完整 Key 发给他人检查。 应撤销已公开的 Key,再创建新 Key。
  3. 同时改 Key、模型、代理和 SDK 版本。 变量太多,成功后也无法确认根因。

修复完成的验收标准

  • /v1/models 使用目标 Key 稳定返回成功;
  • 最小非流式请求成功,并返回可解析正文;
  • 客户端日志显示请求发往预期域名;
  • 旧 Key 已撤销,仓库和日志中没有密钥明文;
  • 401 不再进入自动重试队列。

认证通过后,可以继续使用模型质量检测检查模型声明、Token、SSE 和工具调用;如果出现 404 或模型不存在,转到model not found 与 /v1/v1 排查

已核对来源

参考与核对来源

下一步

先核对模型与价格,再创建独立测试 Key

模型 ID、开放状态和价格会变化;小规模验证通过后再接入生产。

查看模型与价格注册使用 查看 API 文档