调用报错，
先查这几处。

常见提示：invalid_api_key、Unauthorized、令牌无效。

1. 确认客户端填的是 API Key，且没有多余空格或换行。
2. 到 API 密钥查看 Key 是否过期、停用或已删除。
3. 修改环境变量后重新启动客户端，确认当前会话使用的是新配置。

不用把 Key 发到群里。提供错误正文和客户端名称即可开始排查。

先看错误里写的是权限、模型限制、IP 限制，还是额度不足。

1. 对照 Key 的模型范围、分组和 IP 白名单。
2. 若明确提示额度不足，同时检查账号余额和 Key 的额度上限。
3. 接自己的脚本或其他客户端时，GPT 选择标注“可外接”的 Plus / Pro；Sale 组只接 Codex。

查看 Sale / Plus / Pro 的区别 →

model_not_found 也可能以其他状态码返回。先分清是路径不存在，还是所选模型在当前接口或分组中不可用。

1. Base URL 不要填成完整的 /v1/chat/completions 或 /v1/responses 路径，除非客户端明确要求填写完整接口地址。
2. 查看最终请求地址，排除重复的 /v1/v1/。
3. 从 模型广场复制完整模型 ID，并确认它支持 Chat Completions 还是 Responses。

路径返回网页 HTML 而不是 API 错误 JSON 时，优先检查域名、Base URL 和反向代理路径。

也可能是当前上游线路暂时拥挤。根据错误正文区分个人限额和线路容量。

1. 停止连续重试，把并发降到 1，用一条短请求复查。
2. 响应有 Retry-After 时，按指定时间等待；没有时增加重试间隔。
3. 仍然失败，记录模型、分组和发生时间，联系支持核对线路状态。

不要把 429 直接当作余额不足，也不要只凭这一条错误反复充值。

先判断只影响某个模型，还是所有请求都失败。

1. 使用同一模型测试一条短文本，暂时去掉图片、工具调用和超长历史。
2. 查看 使用日志中的状态、Token 和扣费，再决定是否重试。
3. 有请求 ID 时保留请求 ID；没有时记录发生时间，便于客服定位。

客户端超时不一定代表服务端没有处理。先核对日志，避免重复执行任务。