10/20 傍晚续报：pro200 号频繁 503，v0.2.17 不把这条错记在账号上
这一小时四仓零新版本：一条新报障说 pro200 号频繁回 503、同网段的 pro100 没事；v0.2.17 把这句上游过载判成请求级容量让渡，账号表里一个字不写，本文给出两句判据与今天的处置顺序。
北京 15:07 到 16:08 这一小时，四个仓库没有新版本，主干也没动。
唯一的动作是一条新报障：pro200 那批号频繁回 503。
原文是「Our servers are currently overloaded. Please try again later.」，同一服务器网段下的 pro100 反而没事1。
15:38 开单，正文只有一张运维日志截图和一句「pro100 的反而没事」。
15:45 有人跟了一条「+1」。15:47 报障人自己追问，是不是 8 月前开通的老账号被标记了2。
这个问题有一半能从中转本地回答：这条错在 sub2api 里既不标记账号、也不上冷却，账号表里查不到痕迹。
先分清两句 503
运维日志的「响应内容」那一列里，这是两句完全不同的话。
一句是上游原文：「Our servers are currently overloaded. Please try again later.」。
sub2api 认得出它，按请求级容量让渡处理3。
另一句是「No available accounts」，同样回 503，但意思是池子里没号可选4。
第一句说的是上游此刻的容量，第二句说的是你的池子里没号可选。分辨只看这一列，不用翻别处。
报障帖第 1 楼那张图（本人上传的截图）：2026-10-20 15:33:51 到 15:36:41，八条记录全是「上游 / 上游错误 / 503 / 流式」，响应内容都是 Our servers are currently overloaded。不到三分钟八条，落在 15:33 到 15:36 之间。
四步：认出来、先重试本号、不写账号、再换号
第一步是认。三个片段命中任意一个就算：「server is overloaded」「servers are overloaded」「servers are currently overloaded」3。
第二步是两个标志位。命中之后，这条错误被同时标成「可以在同一账号上重试」与「请求级瞬时」5。
GitHub 页面截图，同文件第 324–338 行：第 331 行先判是不是容量让渡，第 336–337 行把两个标志位一起写上去。
这一步不算换号，不占
max_account_switches 的额度6。第四步是重试用尽之后。这里是关键的一句：请求级瞬时故障直接 return，不写账号状态8。
GitHub 页面截图，第 755–759 行：注释写明「请求级瞬时故障与账号健康无关」，第 757 行的提前返回让后面两条封禁分支都走不到。
再往后才轮到换号。
max_account_switches 默认 10，一次请求最多换 10 个号9。流式还有一道分界
截图里八条全是「流式」。流式路径多一个判断：客户端有没有已经收到首块。
没收到，还能重试本号、还能换号；收到了，就只记一条 suppressed 日志，不再换号10。
所以同一句 503，落在首块之前和之后是两种结果：前面是重试或换号之后成功，后面是这一轮到此为止。
pro200 与 pro100 的差别在上游那侧
本地对 OpenAI 账号的 plan_type 只有一层判定：空、free、abnormal 算非订阅，其余算订阅11。
没有 pro200 分支，也没有 pro100 分支。
所以两批号在这条错上表现不同，只能来自上游那侧。你在本地改什么，都不会把 200 那批变成 100 那批。
报障本身的分量也要说清：一个人自述、没写版本号、没贴日志原件，也没有第二个人拿出自己的对照数据。它够得上「留意」；要把它当成「上游在标记老账号」，还缺这三样东西。
今天能做的三步
- 先判层。翻运维日志的响应内容：是上游原文，还是 No available accounts。这一步判错，后面每一步都白做。
- 别动账号表。看到上游原文这句，不要清冷却、不要手动恢复、不要加大换号次数。它压根不写账号状态，换号也不改变降载因素——代码注释的原话是，故障因素（客户端身份、模型容量）在下一个账号上完全相同8。
- 压的是重试和并发。
pool_mode_retry_count保持默认 3；整池都在吃这条错的时候，加并发只会让三分钟八条变成三分钟八十条。
想验证「是不是这批号被区别对待」，办法只有一个：同一模型、同一时段，200 和 100 各打一条，看是不是只有一边吃这条错。这个验证只能在中转外面做。
并列登记：一条挂了三个月的桥接被作者自己撤回
CLIProxyAPI #4465 在 15:58 被作者 Johnnybyzhang 自己关闭，merged=false12。
这张单开在 7 月 20 日，一直挂着 draft，23 个文件 +3218/−125，9 笔提交，base 是 dev。
它要做的事不小：给 Claude 的
/v1/messages 加一条通往 Codex Responses 的桥，普通请求走 /responses，Claude 自己发压缩请求时改走 /responses/compact，带压缩状态的续接请求保持同一张凭据。撤单前唯一一条实测反馈在 2026-08-02：测试者说「完全不可用」。
他把原因写得很具体：压缩胶囊一旦插进普通消息上下文，上游回 403、本地上下文里堆满胶囊。他建议改成服务端缓存13。
作者没有留关闭说明。这条登记留下的是一个代价：压缩状态一旦被塞进普通消息流，换来的是上游 403 加上本地上下文污染。
同小时还有两张认证入口的单，都没合并，也都不该让今天的配置有任何改动。
一张是 sub2api #8238 飞书租户登录，15:17 开、draft、39 文件 +834/−16、默认关闭14。
另一张 #8195 让 Antigravity 支持 Google One 会员授权登录，28 文件 +2419/−191，窗口内只有时间戳变化、提交数仍是 115。
这一小时的其余状态
| 仓库 | 当前发行版 | 主干最新提交 | 窗口内 |
|---|---|---|---|
| CLIProxyAPI | v8.0.35，10-20 03:02 发布16 | main 12:23、dev 12:25 | 一条 PR 自撤 |
| sub2api | v0.2.17，10-16 12:41 发布17 | main 10-19 20:45 | 六条条目变动 |
| codex-proxy | v2.1.19，10-20 05:10 发布18 | dev 10-20 04:57 | 无 |
| codex2api | v3.1.1，10-17 05:46 发布19 | main 10-17 05:35 | 无 |
sub2api 那六条里只有两条是新的：#8239 与 #8238。其余是被顶起来的老条目——#3576（6 月底那条 OAuth 401 缺 scope）、#764 交流长帖、#8148 部署选址帖 15:14 多了一条回复、#8195 只动了时间戳。
上游与额度
- OpenAI 状态页全绿，0 个活动事件、0 个降级组件20。
- Anthropic 全绿，今天没有事件21。
- Google Cloud 的 incidents.json 仍是 7 条，最近一条是 10-08 到 10-09 的 Cloud Storage22。
14:33 那次 Codex 全局重置仍在生效，两家追踪站给出的最近一次重置时刻一致。
codex-reset 记 06:33 UTC、1 小时前、56 次全局 / 10 次 banked、24 小时 22% / 48 小时 39%23。opentherank 记同一时刻、累计 64 次、中位间隔 3.1 天24。
两站累计口径差还在，能用的仍只有「最近一次重置」这一个字段。
官方开发者社区 Codex 分区窗口内没有新话题，最新仍是上一期写过的那条 14:51 的用量归属帖25。
Reddit 窗口内两条：15:43 的「Reset rolled out」、15:08 的「客户端按下停止之后上游还在写」。一条是重置到账，一条是消费端测量，都不属中转运维的新动作，未收。
这一小时没有版本可升。能动手的只有一件事：把「503 就是号坏了」这个直觉改掉。
References
- 1sub2api issue 8239
github.com
- 2issue 8239 的第二条评论
github.com
- 3
- 4gateway_handler.go 第 422 行
github.com
- 5upstream_errors.go 第 324–338 行
github.com
- 6failover_loop.go 第 211–234 行
github.com
- 7account.go 第 1194–1234 行
github.com
- 8gateway_service.go 第 749–767 行
github.com
- 9config.go 第 2435 行
github.com
- 10
- 11account.go 第 1419–1430 行
github.com
- 12CLIProxyAPI PR 4465
github.com
- 13PR 4465 的实测评论
github.com
- 14sub2api PR 8238
github.com
- 15sub2api PR 8195
github.com
- 16CLIProxyAPI releases
github.com
- 17sub2api releases
github.com
- 18codex-proxy releases
github.com
- 19codex2api releases
github.com
- 20OpenAI Status
status.openai.com
- 21Anthropic Status
status.anthropic.com
- 22Google Cloud incidents.json
status.cloud.google.com
- 23codex-reset.com
codex-reset.com
- 24OpenTheRank Codex Reset Tracker
opentherank.com
- 25Codex usage chart attributes ~80% of usage to gpt-6-astra
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.