API 报错时最浪费时间的做法，是同时修改地址、密钥、模型和请求体。正确方法是保存原始响应，一次只检查一个层级。

先保存这五项信息

记录发生时间、状态码、响应体、请求地址和请求 ID。日志中隐藏密钥，只保留前后少量字符用于区分。

401：先检查身份信息

确认 Authorization 格式是 Bearer 空格 + API Key；密钥没有多余引号和换行；当前密钥没有被撤销；请求发送到正确服务。不要把完整密钥贴到群聊或工单。

404：检查地址和路径

常见原因是 Base URL 重复 /v1、调用了当前协议不支持的路径，或者客户端把路径再次拼接。打印最终请求 URL，而不是只看配置页面。

模型不存在或无权限

从 GBAPI 模型广场重新复制真实 model ID，注意大小写、连字符和版本后缀。教程标题中的 GPT‑5.5、GPT‑5.6 系列名不能代替 API 参数。

429：区分限速和额度

如果短时间并发过高，降低并发并使用指数退避：第一次等待约 1 秒，之后逐步增加，并设置最大次数。如果是额度不足或账户限制，重试不会解决问题。

attempt 1 → 等待 1 秒
attempt 2 → 等待 2 秒
attempt 3 → 等待 4 秒
超过上限 → 记录任务并人工处理

5xx：保留请求，有限重试

服务端临时错误可以重试，但要加入随机抖动，避免大量任务同时再次发送。对于会产生副作用的请求，先确认接口是否支持幂等，避免重复执行。

最小化复现

把请求缩小到一条 user 消息，移除工具、图片、流式输出和复杂参数。最小请求成功后逐项加回。这样可以判断问题来自连接、型号还是高级功能。

如果需要微信协助，提供脱敏后的状态码、响应体、发生时间和你使用的客户端版本，不要只发一句“用不了”。

常见问题

遇到 429 一直重试可以吗？

不应该立即无限重试。先判断是速率限制、并发过高还是额度问题，再使用指数退避和最大重试次数。

同一个请求昨天成功今天失败是什么原因？

可能是渠道状态、额度、模型上下架或服务端限制变化。保留请求 ID 和时间，先查看控制台状态再排查代码。