Gemini 项目被限的 403 会被本地写成账号 error；CLIProxyAPI 同号重试与凭据身份两张单还停在 PR 里
Gemini 项目被标 Restricted 之后，那条 403 在 sub2api v0.2.17 里会让整组号被逐个写成 error；CLIProxyAPI 两处改重试与凭据继承的单还停在 PR 里，今晚能做的与不能做的都写在正文。
上一期在北京 15:56 发出，到现在四家仓库都没有新版本：CLIProxyAPI 停在 v8.0.38，sub2api 停在 v0.2.17，codex-proxy 停在 v2.1.20-beta.0543eaa，codex2api 停在 v3.1.1。1234
这半小时要动手的事在上游那一侧。Google 的 Gemini API 分区在中午两个多小时里冒出十条同形态的项目受限帖，而 sub2api 会把这类 403 直接写成账号 error。
Gemini 这一波 403 打在项目上
北京 12:15 到 14:42 之间，Gemini API 分区至少有十条帖子在说同一件事：AI Studio 项目被标 Restricted，Billing Tier 变成 Unavailable，调用回 403。5
报错文本有两种。一种是「Your project has been denied access. Please contact support.」，发帖人补了一句：Cloud Console 里找不到停用通知，也找不到申诉入口。6
另一种是「This Project's API access is restricted. Please set up billing to continue.」，发帖人的两个项目同时被限，免费层的 API 一起停掉。7
Google 在 abuse monitoring 文档里写了处置阶梯：先联系用户了解用途，再调低速率或换模型，然后临时停用，最后才是永久关闭账号。停用或关闭时会附一个申诉链接。8
文档说链接随通知一起给出，论坛里的发帖人在控制台翻遍了也没找到入口。
两个案子展示了两种成因。
一个开发者 10 月 18 日被以「repeated violations of the Terms of Service」停用，10 月 21 日申诉被拒，回信只有一句「will remain closed」，没有指出具体条款。9
另一家斯里兰卡支付公司的生产项目，10 月 13 到 15 日三天跑了约 1.23 亿 token，平时的用量是每天 100 万——发帖人自己判断 key 被外人用了；申诉编号已提交在等回复，云支持工单只退了一笔账单。10
这条形态不新。论坛检索里含 restricted 的帖，10 月 19 日两条、20 日九条、21 日四条、今天二十条；含 PERMISSION_DENIED 的今天九条，10 月 19 日那天二十一条。5
对中转来说，要害在「项目」这两个字：同一个项目下的所有 key 一起 403，重试无用，换 key 也无用。
本地会把这条 403 写成账号 error
sub2api v0.2.17 的 handle403 分了几条路。11
Antigravity 走专用分支，validation、violation、generic 三类都 SetError。
Kimi 的并发型 403 只换号；国产供应商的配额耗尽 403 按 429 冷却到窗口重置；OpenAI 与多协议 key 走 HTML 豁免加累计阈值。
OpenAI 那条分支的注释把理由写明了：403 在 failover 状态集里会被逐账号重放，一次 SetError 足以把整组账号打下线。
剩下的平台落到最后一段：拼一句「Access forbidden (403)」，交给 handleAuthError，然后 return true。
handleAuthError 做两件事：把账号标记为不可调度，再调 accountRepo.SetError 把错误写进账号。12
Gemini 平台没有专门分支，落在这条路上。被限项目回一次 403，这个号就被标 error、停止调度。
连锁在后面。按那段注释的说法，同一轮 failover 里剩下的 Gemini 号会依次撞上同一条 403，依次被标 error。
sub2api v0.2.17
backend/internal/service/ratelimit_service.go 第 1006–1043 行：Antigravity、Kimi、国产供应商、OpenAI 各有分支，其余平台（Gemini 在此列）落到第 1041 行 s.handleAuthError。截图取自 v0.2.17 标签。CLIProxyAPI 两张还开着的单
北京 16:13 开出的 #6874 加了一个新配置键
routing.retry.same-upstream-retry，默认 0；28 个文件、+1711/−82。13它管换号之前那一步：同一条凭据、同一个实际上游模型上多试几次，试完再换号。
适用 408、500、502、503、504 与 520–526，以及可重试的连接失败。
401、403、429 与请求级故障不在此列；流式请求在第一个负载之后不再重放。
每次尝试单独一个 execution sequence，恢复时不会清掉更新的冷却。
作用域包含普通执行、token 计数、流式、Antigravity 的额度回退与 Home 选择恢复。
与既有的 request-retry 分开看就清楚：request-retry 是第一轮凭据用完之后追加凭证轮次，也就是换号；新键在换号之前先在原地重试。14
现在改不到。v8.0.38 与 dev 的 config.example.yaml 都没有这个键，要等它合并进版本再升级。
自动评审这一轮没跑完：16:13:50 那条汇总写的是 Review Failed，「We couldn't complete this review」，
has_unresolved_findings 为 true，需要作者重跑一次。13
#6874 头分支
sdk/cliproxy/auth/conductor_same_upstream_retry.go 第 28–48 行：只有 408/500/502/503/504/520–526 与可重试连接失败会再试，401/403/429 落 default 分支返回 false。另一张是 #6853，16:10:42 落了新提交 144c9cfc，状态从 dirty 转成 clean，改动收敛到 3 个文件。15
它修换号之后「新号继承旧冷却」：auth 文件被整份重写时（换 provider、换另一个 Codex 账号、换 Vertex 服务账号、插件存储轮换），路径派生的 ID 不变，新凭据把旧凭据的 Status、冷却与模型状态一起接了过来，然后一直不可选。
修法是一行判定：
carryRuntime := isFileSnapshot && !credChanged && 同 provider。CredentialsChanged 也扩到了 codex 的 account_id、Vertex 的 project 与 service_account、插件 storage 的原始 JSON。跑 dev 的实例今晚别在 auth 目录里直接替换账号文件，等这张单合并。
#6853 头分支
sdk/cliproxy/auth/conductor_lifecycle.go 第 378–398 行：第 386 行把继承条件收窄成「文件快照 + 凭据没变 + provider 相同」，其余情况按全新凭据起步。sub2api 的 #8295 已经从草案转成正式，测试提交补齐到三笔，仍然开着。17
上游读数
Anthropic 的 Connectors 事件在北京 16:07:03 转为 resolved，原文是「The issue affecting claude.ai and Claude Cowork has been resolved.」。状态页现在没有降级组件。18
OpenAI 那条仍停在 monitoring，最后一条更新是北京 10:42，到发稿时五个多小时没有新动静。Responses 与 Conversations 仍标着 degraded。19
Codex 的重置没有落地。codex-reset 首页写「No — not so far today (UTC)」，最近一次已验证的全局重置是 10 月 20 日 14:33（北京），累计 56 次、banked 10 次，24 小时概率 22%、48 小时 39%。20
另一家追踪站记 64 次、中位间隔 3.1 天、最长 68 天。两家的累计数不同，引用时各按各的口径。21
Tibo 的两条帖都发在北京 14:55，跟帖写的是「Lands tomorrow before 10am PST」，对应太平洋时间 10 月 22 日上午 10 点，也就是北京 10 月 23 日 01:00 之前。22
今晚四件事
- 把被限项目下的 Gemini 号先摘掉：在 sub2api 里手动停用，或者从分组里移出，别让 failover 逐个撞 403 把整组标成 error。
- 在 AI Studio 里确认该项目的 Status 与 Billing Tier；申诉走 Google 停用邮件里的链接，云支持工单走的是账单那条线。
- 要试 same-upstream-retry 别直接拉 dev 分支：新键只在 #6874 里，而 dev 上还有 #6853 要修的那段继承行为。
- Codex 重置落地之后，先看
/status的窗口行，再看本地凭证级冷却。上游那边刷新完，本地这层要手动 reset 才会动。
References
- 1CLIProxyAPI releases
github.com
- 2sub2api releases
github.com
- 3codex-proxy releases
github.com
- 4codex2api releases
github.com
- 5Google AI Developers Forum 检索 restricted
discuss.ai.google.dev
- 6Gemini API 403 PERMISSION_DENIED - Project Restricted
discuss.ai.google.dev
- 7Gemini Project and Key Restricted
discuss.ai.google.dev
- 8Abuse monitoring | Gemini API
ai.google.dev
- 9Default Gemini Project closed after appeal
discuss.ai.google.dev
- 10Urgent Escalation Request – Gemini API Restriction
discuss.ai.google.dev
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18Elevated errors affecting Connectors
status.claude.com
- 19
- 20Codex Reset
codex-reset.com
- 21Codex Reset Tracker
opentherank.com
- 22Tibo on X
x.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.