跳转到内容
OfApp 知识库
首页快速开始Codex 教程GPT ImageAI 工作流AI 办公常见问题打开 API 入口
API 入口

API 错误排查

invalid API key

invalid API key 排查指南讲清 API Key 无效、Bearer 请求头、Base URL 匹配、密钥链路检查、部署 Secret、日志脱敏和密钥轮换。

预计阅读
8 分钟
最近更新
2026/07/03
维护方式
人工编辑

invalid API key 表示服务端没有接受当前 API Key。它通常不是模型参数、Prompt 或网络速度问题，而是密钥本身、请求头、环境变量、Base URL 或部署 Secret 之间有一环不匹配。

OpenAI 官方 API 认证文档要求在请求中使用 HTTP Bearer 认证，也就是 Authorization: Bearer <API_KEY>。如果你使用 OfApp.cn 这类 OpenAI-compatible API 入口，也应先确认 Key、Base URL 和请求头是否来自同一 套配置；具体可用模型、能力、价格和额度请以 OfApp.cn 控制台或官方文档为准。

页面摘要

Section titled “页面摘要”
项目 内容
阅读时间 约 6 分钟
更新时间 2026-07-03
适合读者 AI 初学者、开发者、产品和运营、团队管理员，以及正在配置 OpenAI-compatible API 的用户
核心问题 为什么同一个请求会报 invalid API key，以及如何确认 Key、Base URL、Bearer 请求头和部署 Secret 是否匹配
你会完成 最小 cURL 验证、密钥链路检查、部署环境排查、OfApp.cn 场景复核、日志脱敏和 Key 轮换清单
边界提醒 本页不承诺具体模型、价格、额度、套餐或账号权限；涉及 OfApp.cn 时请以 OfApp.cn 控制台或官方文档为准

适合谁读

Section titled “适合谁读”
读者 典型场景 读完能解决什么
AI 初学者 刚拿到 Key，照着教程请求失败 知道 Key、Base URL 和模型名要分开检查
开发者 本地能跑，部署后报 invalid API key 定位环境变量、Secret 和运行时加载问题
产品和运营 使用 AI 客户端、插件或网页工具 判断是 Key 填错、服务商填错还是旧配置未生效
团队管理员 轮换 Key 后部分任务失败 建立轮换、脱敏和最小验证流程

如果错误信息同时出现 401、unauthorized 或 invalid API key，可以先按本文排 查。若错误变成 403、429 或 model not found，再转到对应错误页。

判断流程图

Section titled “判断流程图”
确认 Key 来源控制台 当前账号加载环境变量终端 进程 部署检查请求头Authorization Bearer匹配 Base URL同一服务商跑最小请求先不用 SDK必要时轮换撤销旧 Key

这条流程的重点是“缩小范围”。先确认请求里真的带了当前 Key，再判断 Key 是否 属于当前 Base URL，然后再进入 SDK、客户端或业务代码。

invalid API key 是什么

Section titled “invalid API key 是什么”

invalid API key 的直观含义是：服务端看到了某种鉴权信息，但无法把它识别为 有效密钥。常见表现包括：

表现 更可能的问题
一直返回 401 或 unauthorized Key 为空、请求头缺失或 Bearer 格式错误
明明复制了 Key 仍失败 多了空格、换行、引号或粘贴到了错误字段
本地成功，线上失败 部署平台没有配置 Secret，或运行时没读到变量
昨天能用，今天突然失败 Key 被撤销、轮换、过期策略变化或账号状态变化
A 工具可用，B 工具失败 两个工具读取的 Base URL、Key 或配置文件不同

它和 401 Unauthorized 很接近，但 invalid API key 更聚焦于“密钥无效或不被接 受”。401 还可能只是没有发送 Authorization 请求头。

密钥链路检查矩阵

Section titled “密钥链路检查矩阵”

排查 invalid API key 时，不要只盯着 Key 字符串本身。一次请求能否通过鉴 权，取决于“谁创建了 Key、谁读取了 Key、请求发到哪里、请求头怎么写”这条链 路是否一致。

链路节点 要确认什么 建议验证方式
Key 来源 Key 来自当前账号和当前服务入口 从 OfApp.cn 控制台或当前服务商控制台重新复制
运行时读取 当前进程真的读到了非空 Key 打印长度或脱敏摘要，不打印完整值
请求头 使用 Authorization: Bearer ... 用 cURL 最小请求绕开 SDK
Base URL Key 和 Base URL 属于同一入口 OfApp.cn 示例使用 https://api.ofapp.cn/v1
SDK 配置 SDK 没读到旧环境变量或旧客户端配置 重启进程，检查初始化参数和 .env 加载顺序
部署 Secret 生产、预览、CI 环境都配置了同名变量 更新 Secret 后重新部署或重启服务
泄露处理 一旦完整 Key 进入日志或截图 立即轮换 Key，并清理公开记录

如果这张表有任何一项无法确认，先不要继续调模型参数、Prompt 或业务逻辑。鉴 权失败发生在模型调用之前，改 Prompt 不能修复无效密钥。

先不要做什么

Section titled “先不要做什么”
不建议的动作 为什么
反复重试同一个请求 Key 错了不会靠重试变对，还可能浪费用量和日志空间
先改 Prompt 或模型参数 鉴权失败时请求还没进入模型层
把完整 Key 发给同事或 AI API Key 是敏感凭据，一旦泄露应立即轮换
同时改 SDK、Base URL、模型名和代理 变量太多，无法判断是哪一步修好了问题
只看本地终端，不看服务端运行时 部署环境和本地 shell 经常不是同一套环境变量

更稳的做法是保留一个最小请求，每次只改一个变量。

常见原因

Section titled “常见原因”
原因 如何识别 处理方式
Key 为空 OPENAI_API_KEY 长度为 0，或进程启动前没有加载 .env 重新设置环境变量，重启服务或终端
复制损坏 多了空格、换行、中文引号或不可见字符 从控制台重新复制，不手动输入
Bearer 头写错 请求头不是 Authorization: Bearer ... 按官方认证写法修正请求头
Key 与 Base URL 不匹配 用 OfApp.cn Key 请求其他服务，或反过来 让 Key、Base URL 和模型来源保持一致
读到了旧 Key 改了 Secret 但服务未重启，或多个配置文件冲突 打印脱敏摘要，确认运行时实际读取的值
Key 已撤销或轮换 老任务突然失败，新 Key 可用 删除旧 Key，更新所有运行环境
前端暴露 Key 浏览器请求或打包产物里出现真实 Key 改为服务端代理，并轮换泄露的 Key

如果你使用 OfApp.cn，Base URL 示例通常写作 https://api.ofapp.cn/v1。如果某 个客户端会自动拼接 /v1，则应按客户端文档和 OfApp.cn 当前说明填写，避免 最终请求路径被拼错。

5 分钟快速排查

Section titled “5 分钟快速排查”
  1. 确认 Key 来源：从当前账号的控制台重新复制，不使用截图、聊天记录或旧文档。
  2. 检查环境变量长度：只看是否存在，不打印完整 Key。
  3. 检查 Base URL：确认它和 Key 来自同一服务商。
  4. 用 cURL 跑最小请求：先绕开 SDK、前端框架和业务代码。
  5. 如果 cURL 成功，再检查 SDK 初始化、部署 Secret、客户端配置和代理。
  6. 如果 cURL 仍失败，重新生成 Key 或到控制台确认账号、额度、权限和模型可用性。

不要把真实 API Key 写进工单、截图、GitHub issue、聊天记录或日志附件。需要 别人协助时，提供脱敏后的长度、前后少量字符、请求 URL、状态码和响应体即可。

最小验证命令

Section titled “最小验证命令”

下面命令只验证三件事：环境变量是否存在、Base URL 是否通、Bearer 请求头是 否被接受。示例 Key 使用占位符，真实 Key 请从控制台复制到本机环境变量。

Terminal window
export OPENAI_API_KEY="sk-xxxx"
export OPENAI_BASE_URL="https://api.ofapp.cn/v1"


echo "key length: ${#OPENAI_API_KEY}"


curl "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

如果服务商不支持 /models，可以换成该服务商文档推荐的最小端点。排查目的 不是调用复杂任务，而是先证明 Key、Base URL 和请求头三者能互相匹配。

本地环境怎么查

Section titled “本地环境怎么查”

不同运行方式会读取不同环境。你在终端里 echo 成功，不代表 Node、Python、 Docker、IDE 或后台进程都读到了同一个值。

场景 检查方式 注意事项
终端脚本 echo ${#OPENAI_API_KEY} 只打印长度，不打印完整 Key
Node.js 检查 process.env.OPENAI_API_KEY 是否存在 修改 .env 后重启 dev server
Python 检查 os.environ.get("OPENAI_API_KEY") 是否存在 Notebook 内核可能要重启
Docker 检查 docker run -e、Compose environment 或 Secret 不要把 Key 写进 Dockerfile
IDE 插件 打开插件自己的配置页 插件可能不读取 shell 环境变量

如果你用 Codex、Claude Code、OpenClaw、Cherry Studio、LobeChat 或类似工具， 还要确认工具内部没有保存旧 Key 或旧 Base URL。

部署环境怎么查

Section titled “部署环境怎么查”

线上 invalid API key 很常见，因为部署平台的构建环境、运行环境和本地终端是 三套不同上下文。

检查项 问自己
Secret 是否存在 生产环境和预览环境是否都配置了 OPENAI_API_KEY？
变量名是否一致 代码读的是 OPENAI_API_KEY，平台里是否写成了别的名字？
是否需要重启 更新 Secret 后，服务、函数或容器是否重新部署？
构建时还是运行时 代码是在 build 阶段读取 Key，还是请求发生时读取？
日志是否脱敏 错误上报、控制台日志和请求拦截器有没有打印完整 Header？

部署环境里最该记录的是“是否读取到值”和“请求失败状态”，不是完整密钥。

OfApp.cn 场景检查

Section titled “OfApp.cn 场景检查”

OfApp.cn 可以作为 OpenAI-compatible API 入口。排查 invalid API key 时，重 点看这几件事：

检查项 建议
Key 来源 从 OfApp.cn 当前账号控制台创建或复制，不混用其他服务商 Key
Base URL 常见写法为 https://api.ofapp.cn/v1，具体按 OfApp.cn 当前文档填写
客户端路径 有些客户端填 host，有些填完整 /v1，不要重复拼接
模型名 从控制台或官方文档复制，不凭教程旧截图猜
价格与额度 不在错误页里承诺，统一以 OfApp.cn 控制台或官方文档为准

如果同一把 Key 在天才游乐场可用，但在某个客户端不可用，优先检查客户端保存 的 Base URL、Key 字段、模型字段和代理设置。

日志脱敏模板

Section titled “日志脱敏模板”

把问题发给同事或 AI 排查前，可以按下面模板整理。保留定位所需信息，删除敏 感内容。

时间：YYYY-MM-DD HH:mm
环境：本地 / 预览 / 生产
请求方法：GET
请求路径：/v1/models
Base URL：https://api.ofapp.cn/v1
状态码：401
错误摘要：invalid API key
Key 摘要：长度 64，开头 sk-xxxx，结尾 xxxx
已确认：没有打印完整 Authorization header
最近改动：刚轮换 Key / 刚部署 / 刚改客户端配置

不要把完整 Authorization、Cookie、访问令牌、用户材料、内部地址或业务数 据贴进日志。无法确定是否泄露时，先轮换 Key。

修复后怎么防止复发

Section titled “修复后怎么防止复发”
做法 好处
每个环境使用独立 Key 生产和测试互不影响，泄露时容易定位
Key 只放 Secret 或环境变量 避免进入仓库、前端包和截图
部署后跑健康检查 及时发现 Secret 没加载或路径错
记录脱敏请求 ID 和状态码 方便回溯，不暴露密钥
给 Key 轮换留清单 避免某个定时任务继续使用旧 Key
在 PR 检查里扫描 sk- 降低误提交真实 Key 的概率

密钥排查看起来琐碎，但一旦形成固定清单，后续的 SDK、模型和业务错误会更容 易分层定位。

示例报错

Section titled “示例报错”

不同服务商的字段名称可能不同，但含义通常接近。

{
  "error": {
    "message": "Invalid API key",
    "type": "invalid_request_error"
  }
}

看到这个错误时，优先保留状态码、请求路径和脱敏响应体。不要为了复现问题而 把完整 Key 写进 issue 或聊天窗口。

常见问题

Section titled “常见问题”

invalid API key 和 401 Unauthorized 一样吗？

Section titled “invalid API key 和 401 Unauthorized 一样吗？”

不完全一样。invalid API key 更明确地指向密钥无效、不可识别或不匹配；401 Unauthorized 还可能是没有发送 Authorization 请求头，或 Bearer 格式写错。

为什么我复制了新 Key 还是失败？

Section titled “为什么我复制了新 Key 还是失败？”

可能是进程仍在读取旧环境变量，客户端保存了旧配置，部署平台没有重新发布， 或复制时带入了空格、换行和引号。先用最小 cURL 请求验证当前运行时读到的值。

可以把 API Key 打印到日志里排查吗？

Section titled “可以把 API Key 打印到日志里排查吗？”

不可以。最多打印长度、是否为空、前后少量字符和配置来源。完整 Key 一旦进 入日志、截图或聊天记录，就应视为泄露并轮换。

本地可以，线上 invalid API key 怎么办？

Section titled “本地可以，线上 invalid API key 怎么办？”

先查部署平台 Secret。确认变量名一致、生产和预览环境都配置、更新后已重新 部署，并确认代码是在运行时读取环境变量，而不是构建时读到空值。

OfApp.cn Key 可以用于所有 OpenAI 客户端吗？

Section titled “OfApp.cn Key 可以用于所有 OpenAI 客户端吗？”

前提是客户端支持 OpenAI-compatible Base URL 配置，并且填入的 Base URL、 Key 和模型名符合 OfApp.cn 当前文档。不同客户端对 /v1 拼接方式不同，配置 时要按客户端说明检查最终 URL。

Key 泄露后只删除日志够吗？

Section titled “Key 泄露后只删除日志够吗？”

不够。删除日志不能保证别人没有看到或复制。应立即撤销或轮换 Key，检查仓库 历史、部署环境、错误上报、聊天记录和截图。

重试能解决 invalid API key 吗？

Section titled “重试能解决 invalid API key 吗？”

通常不能。invalid API key 是鉴权配置问题，不是临时网络抖动。先修 Key、请 求头、Base URL 和环境变量，再考虑重试策略。

资料来源

Section titled “资料来源”
  • OfApp.cn 首页：用于核对 OfApp.cn 当前公开的 API Key、Base URL、OpenAI、Codex、GPT Image、Claude 和天才游乐场入口。
  • OfApp.cn API 文档：用于核对 OfApp.cn 公开的 /v1、Bearer 鉴权、Models API、Responses、Chat Completions 和兼容接入示例。
  • OfApp.cn 天才游乐场：用于区分网页体验入口和 API Key 接入排查路径。
  • OpenAI API Authentication：用于核对 Bearer 凭证、API Key 保密、服务端环境变量和密钥管理边界。
  • OpenAI SDKs and CLI：用于核对 SDK/CLI 读取 API Key 环境变量的通用做法。

相关文章

Section titled “相关文章”

带走什么

Section titled “带走什么”

invalid API key 先查密钥链路：Key 是否来自当前控制台、环境变量是否被运行 时读取、请求头是否是 Authorization: Bearer、Base URL 是否和 Key 匹配。 最小请求通过后，再处理 SDK、客户端、模型和业务代码。真实 Key 不进日志、 前端、仓库、截图和聊天记录；无法确认是否泄露时，直接轮换。