|
|
调用 AI API 时，401 和 429 都很常见，但解决方向不同。401 通常意味着认证未被接受；429 通常与请求限制有关，一些服务也用它表示配额或账单额度不足。实际原因必须结合错误正文、响应头和服务商说明判断。
一、401：先查认证，不要先改提示词
常见原因包括：Key 拼写错误、复制时带入空格或换行、密钥已撤销、请求发往错误服务，以及认证头格式不符合接口要求。
不同服务商签发的 Key 通常不能互换。一个服务商的密钥不应发送给另一个平台，即使两者都声称兼容同一种接口。
部分 API 使用 Authorization: Bearer 形式，另一些使用其他头或认证机制；应按官方文档设置，不要在客户端中随意重复添加 Bearer 前缀。
二、401 的检查顺序
1. 核对请求主机和 API 地址是否属于预期服务。
2. 在官方控制台检查密钥状态、项目归属和必要权限。
3. 重新复制密钥到可信客户端，避免泄露到在线测试工具。
4. 检查该客户端要求的是“原始 Key”还是完整认证内容。
5. 用有权限的模型做一次简短测试，记录脱敏后的错误码与请求 ID。
如果怀疑密钥暴露，应撤销旧 Key 并创建新 Key。不要仅靠不断重试解决认证错误。
三、429：区分速率限制和额度限制
速率限制：短时间请求过多、并发过高，或输入输出 token 超过某个时间窗口允许的数量。不同账户、项目和模型的限制可能不同。
额度限制：某些服务用 429 表示余额不足、预算耗尽、试用额度结束或 API 账单未开通；另外一些服务使用其他状态码。
因此，“429 一定是余额不足”与“429 只要等一下就好”都不准确。阅读返回的 error code、type、message，并检查账户账单和额度页。
四、速率限制怎么处理？
减少并发，把请求排队；缩短无必要的上下文，并设置合理的输出长度上限。避免多个客户端或后台任务共用同一配额却彼此不知情。
若服务返回 Retry-After 或限流相关响应头，可按文档利用这些信息。重试应有最大次数、等待间隔和随机抖动，通常采用逐步增加等待时间的退避策略。
不要无延迟地无限重试，也不要用大量新账号或密钥规避平台限制。确有业务需求时，按官方流程申请提高配额。
五、额度或账单问题怎么处理？
在服务商官方控制台检查 API 余额、项目预算、支付状态和模型权限。网页聊天会员通常不等于 API 额度，具体看该平台产品条款。
续费或提高预算前先核对用量和异常请求。如果实际使用量与预期不符，应检查是否有 Key 泄露、测试程序循环或错误重试。
账单变更可能不立即同步，遵循服务商提示；盲目重试不会自动补足额度。
六、还有哪些相关错误？
400：常见于参数或请求格式问题，也可能是上下文等限制。
403：常见于权限或策略拒绝。
404：可能是路径、路由或模型不存在。
5xx：可能是服务或网关异常，查看官方状态信息。
连接超时：不一定是 HTTP 错误，也不能直接判断为认证失败。
不同服务的含义有差异，不能仅凭这张列表认定根因。
七、重试前注意成本与重复执行
请求超时或连接中断，不代表服务器一定没有处理请求。重发可能造成重复费用，带工具调用的流程还可能重复执行外部操作。
对支付、发信、修改资料等有副作用的操作，应使用系统支持的幂等和去重机制，并确认前次结果。不要把自动重试直接套用到所有业务。
八、向客服或社区求助的模板
客户端与版本：____
服务商与接口类型：____
模型 ID：____
发生时间、时区和请求 ID：____
HTTP 状态码及脱敏错误内容：____
是否高并发、是否有剩余额度：____
已做的检查：____
不要公开 Key、Authorization 头、包含令牌的完整 URL 或用户的原始敏感输入。
总结
401 优先查身份认证，429 优先区分速率与额度。正确地址、有效密钥、可用模型、合理并发和清晰账单，是稳定调用 API 的基础。
|
|
发表于 2026-10-9 17:48:49