Gemini 403 验证风控排查：额度正常，为什么还是不能用？

最近几天，我的 gemini-3.7-flash-high 持续失败。最初是 auth_unavailable，后来变成了 403 Verify your account to continue。请求链路是 Hermes → New-API → CPA → Antigravity → Google Cloud Code。

这次排查的结论很明确：额度没有耗尽，New-API 和 CPA 的链路正常，换香港、新加坡、美国出口也没有恢复；目前更像是 Google Cloud Code 的账号验证或资格状态异常，CPA 的请求指纹可能是触发因素之一，但还不能单独定性。

错误发生在哪一层

CPA 日志返回：

text 复制代码

403 | upstream execution failed
provider=antigravity
model=gemini-3.7-flash-high
reason=VALIDATION_REQUIRED
domain=cloudcode-pa.googleapis.com
message=Verify your account to continue.

New-API 侧看到的是：

text 复制代码

auth_unavailable: no auth available

后一个提示容易让人误以为 CPA 没有认证文件。实际情况是：CPA 能加载 OAuth 文件，也能完成重新授权；但 Google 在真正调用 Cloud Code 时拒绝请求，CPA 随后把账号标记成暂时不可用。

AI 请求链路：Hermes → New-API → CPA → Antigravity → Google Cloud Code → Gemini

额度正常，不等于调用资格正常

我直接查询了底层额度：

text 复制代码

Gemini 周额度：100%
Gemini 5 小时额度：100%

因此这不是普通的 QUOTA_EXCEEDED，也不能解释为订阅自然到期。Quota 代表剩余调用量，Eligibility/Validation 代表账号是否被允许使用具体服务，两者不是一回事。

VPC 和代理链路没有断

VPC 中 new-api 和 cli-proxy-api 均为 healthy。失败请求从 New-API 到 CPA 只需十几到二十几毫秒，完整请求到达 Google 后才返回 1～2 秒左右的 403。因此请求已经进入 CPA 和 Antigravity，不是 Docker 网络断开。

我还切换了香港、新加坡和美国出口。三个节点都能建立 HTTPS 连接，但最终结果仍是 403 VALIDATION_REQUIRED。

所以不能简单归因于某个香港 IP。IP 可能参与风控，但换节点不会自动清除账号侧的验证状态。

回滚 CPA 也没有解决

我保持认证目录、代理和 New-API 渠道不变，把 CPA 从 v7.3.17 回滚到 v7.2.149，真实请求仍然返回：

text 复制代码

HTTP 403 Verify your account to continue.

这至少排除了“只有 v7.3.17 才会失败”。社区提到的 v7.2.50 和 CLI/Hub User-Agent 差异，仍然值得做 A/B 测试，但暂时不能写成确定结论。

公开讨论中的两条线索

有用户反馈，打开 Google Cloud Shell 完成一次验证后恢复：

text 复制代码

https://shell.cloud.google.com

Google 官方论坛中也出现过同设备、同网络但只有某个账号持续 Account Not Eligible 的案例，这更接近账号级后端状态。

CLIProxyAPI Issue #4272 则有人报告，同一 OAuth 文件在不同版本下结果不同，单账号切换 CLI User-Agent 后恢复；维护者提醒这可能影响部分模型，不能全局套用。

这些讨论能缩小范围，但不能替代本地实测。对我这次故障来说，旧版 CPA 已经验证过仍然失败，因此账号验证状态仍是首要嫌疑。

下一步排查顺序

用同一个账号打开 Cloud Shell，完成可能隐藏的二次验证；
如果仍无提示，再尝试 Antigravity 2.0 重新初始化；
有条件时测试 CPA v7.2.50；
最后只针对问题账号做 CLI/Hub User-Agent A/B 测试。

现在不建议继续重复刷新 OAuth。OAuth 登录成功，只能证明授权流程完成，不代表 Cloud Code 已允许实际调用。至少目前可以确定：这不是简单的订阅到期，真正失败的是 Google Cloud Code 对账号或请求环境的验证。