Gemini接口报错403 quota exceeded

当Gemini接口返回 403 quota exceeded，说明上游配额已用尽或频率超限。
在中转层面做自动降级，最简单可靠的做法是：给中转平台再配一个备用上游渠道，并让Gemini的模型名自动映射到备用渠道。
这样主渠道报403时，请求会自动落到备用渠道，业务不会中断。
本文以常见的new-api中转程序为例，讲清楚配置步骤和验证方法。

先确认报错来自上游还是中转

在改配置之前，先用 curl 直连 Gemini 上游接口，看是否同样返回 403。
如果直连也报 quota exceeded，说明是Gemini官方配额问题，中转层自动降级是有效解法；
如果直连正常，则要检查中转渠道的 Key、模型名或IP限制。

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=你的API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"hello"}]}]}'

返回 403 且 body 里带 quota exceeded，基本可以确认是上游配额耗尽。

在中转层配好备用渠道和模型映射

采用自动降级前，需要先准备一个备用模型，比如另一种 Gemini 型号、OpenAI 的模型或国内大模型。
不用改业务代码，只改中转平台里的渠道配置。

1. 登录中转后台，进入 渠道 → 添加渠道。
2. 类型选择备用模型的提供方，比如 DeepSeek 或 Azure OpenAI。
3. 填入对应的 API Key 和接口地址，把“权重”设为 1（数值越小越优先，视平台而定）。
4. 回到 模型映射 或 模型重定向，新增一条映射：将 Gemini 的模型名（如 claude-3-5-sonnet）映射到备用模型的真实模型名（如 deepseek-chat）。

如果用的是 one-api 或 new-api，通常支持两种方式：

• 在渠道内配置“支持的模型”时，把备用渠道也勾选上 Gemini 的模型名；
• 使用模型映射，将不支持的模型名转换为备用模型名。

这样请求到达中转时，如果 Gemini 渠道返回 403，平台会自动尝试下一个可用渠道（即备用渠道），实现降级。

配置时注意这几点，避免降级失败

• 不要只配一个备用渠道：如果主渠道和备用渠道都是同一供应商，配额是共享的，降级效果有限。最好选不同供应商的模型。
• 模型名称必须映射正确：如果映射后的模型名在备用渠道里不存在，会继续报错。可在备用渠道的“测试”按钮里直接发一条测试请求确认。
• 超时时间别设太短：Gemini 返回 403 通常很快，但备用渠道建立连接可能稍慢。建议把超时时间设置为 30 秒以上，避免误判失败。
• 别让降级模型也报 quota exceeded：如果备用渠道本身被限流，自动降级还是会失败。可以在备用渠道里设置“权重”和“禁用”，一旦连续失败自动标记下线。

验证自动降级是否生效

配置完成后，先在中转后台把主渠道临时停用，再用原请求地址测试：

curl "http://你的中转地址/v1/chat/completions" \
  -H "Authorization: Bearer 中转KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gemini-1.5-flash","messages":[{"role":"user","content":"测试"}]}'

如果返回的是备用模型的回复内容，说明降级链路通了。
接着重新启用主渠道，再次发送同样请求，并用以下命令查看实时日志：

docker logs -f new-api --tail=50

观察日志中渠道 ID 的变化：第一次请求主渠道，第二次请求自动切换到了备用渠道，就代表自动降级正常。
还要检查响应时间，如果多次切换后延迟明显增加，可以调整渠道权重或增加一个同类型新渠道分担压力。

如果你使用的是其他中转程序，思路相同：先确认上游 403，再添加备用渠道并做模型映射，最后用停用主渠道的方式验证。
这样 Gemini 接口报 403 quota exceeded 时，中转层就能自动兜底，不用每天守着后台手动切换。