1700 条过载被吸收，675 条漏出去——都卡在换不到号的那一刻
sub2api 把 1700 条过载吸收掉之后，仍有 675 条落到客户端；本期拆开卡住它们的三处判定，并核清那张池恢复补丁为何进不了任何发行版。
北京时间 14:19，sub2api 上开了一条不像报障的 issue。
#8305 的作者把这三天生产环境的错误账翻了出来：分类、计数、给根因。1
他跑的就是带着 #8305 的那版 main。所以这份数据回答的是「补丁生效之后还剩什么」。
窗口是北京 14:05 到 15:0x。四个仓库零新版本，CLIProxyAPI 的 main 与 dev 都停在窗口之前。
一、近三天的 675 条是什么
他按客户端看到的错误分了四类。
| 类别 | 客户端看到 | 近三天数量 |
|---|---|---|
流内 server_is_overloaded，被重试或换号吸收 1 | 200 | 约 1700 |
| 同上，同账号重试三次用尽 1 | 503 | 约 195 |
流内 server_error，输出之前 1 | 502 | 约 80 |
选号失败：No available OpenAI accounts 1 | 503 | 约 400 |
1700 条被吸收掉，675 条落到客户端。这就是标题里的那个数。
675 里约 400 条源于池里没有可调度的号，改代码修不掉。
跟这次补丁有关的，是 195 加 80 这 275 条。
另有一句比数字更管用：部署之后某个时段，客户端可见错误 100% 来自「可调度账号只剩 1 个」的窗口。2
二、换号耗尽之后，502 只试一次
先看那 80 条。流内的
server_error 在 v0.2.17 里被归成 502。3它能不能在同一个号上多试几次，取决于一个布尔字段。
这个字段为真只有两个来源：失败属于请求级降载，或者这个号是池模式、且状态码落在同账号重试清单里。4
池模式那份清单的默认值只有 401、403、429。5
502 不在里面。于是这条路是：试一次，换号，换不到，报错。
换不到时落到
handleFailoverExhausted，再经 mapUpstreamError 变成 502 与 Upstream service temporarily unavailable。6那 195 条走另一条：过载被认出来，同账号重试三次（合计四次尝试）用完，池里没有第二个号。7
三、模型级瞬时冷却，把整池挡在门外
第二处是他点名的放大点。
同一个「账号+模型」连续失败两次，冷却 10 秒；三次及以上，冷却 45 秒。8
backend/internal/service/openai_account_model_transient.go 第 106–126 行：第 112–116 行按 failureStreak 分两档，三次以上取 45 秒、正好两次取 10 秒，第 119 行把它们写进 blockUntil。(openai_account_model_transient.go) 关键在于这个判定没有放行分支。
isOpenAIAccountRequestRuntimeBlocked 第 569 行直接把模型级结果返回，后面就结束了。9
backend/internal/service/openai_account_runtime_block_fastpath.go 第 556–570 行：第 562–568 行先处理账号级的本地封锁，还留了一个 CAS 兜底；第 569 行把模型级判定直接返回，这一行没有任何旁路条件。(openai_account_runtime_block_fastpath.go) 账号多的时候，它把请求引到别的号，这是对的。
只剩一两个号的时候，同一波过载会把仅有的候选全部挡在门外。
一次可恢复的抖动，就这样被放大成「无可用账号」503。
那 400 条里有相当一部分来自这里。
四、作者补丁的 30 分钟，和它为什么进不了你的版本
他给了自己的分支，三件事。1
一是选号失败时忽略「账号+模型」的瞬时冷却再选一次；账号级封禁、限流、配额暂停照旧。
二是池恢复：换过号、且最后一次错误是请求级降载或 5xx 时，按上游给的等待时间等一等，清空本请求的排除集合重选，最多三轮、单次最多 8 秒。
三是同时覆盖
/v1/responses 与 /v1/chat/completions。30 分钟的成绩：成功 52 条，网关内部吸收 11 条，客户端可见错误 1 条，而且是 499、客户端自己断开的。2
那条 499 的经过他写得很细：三个可调度号在约四分钟里全部返回过载，网关重试约两分钟，日志里能看到「忽略模型冷却后重新选号」按预期触发，之后客户端断开。
修复前，同类情况直接回 502 或 503。
然后是这一期最该记住的一句：这条 issue 开单不到两分钟，被作者本人关成了 not_planned。1
他的分支和镜像之外，仓库里没有对应的 PR。你现在拉 v0.2.17 没有这三处，等下一版也要先等它进主干。
五、那个「换 WebSocket 就降下来」的说法，证据读反了
他给了一个能立刻动手的方向。这一节要泼一次冷水。
他写：官方 Codex 内置的 provider 是
supports_websockets: true，原生客户端走 WebSocket。经网关转发、账号又没开对应开关时，全部以 HTTP 出站。
接着引 codex-lb #2425：过载波次里 HTTP 准入被拒 35%，复用 WebSocket 只有 4.3%。10
本刊读了那份实测。两个数都在，读法反了。
原文的结论是：两边都在 WebSocket 上游，差别在于有没有走 HTTP responses 会话桥。35.3% 那一侧是带图请求主动绕开了桥，4.3% 那一侧是走了桥。10
原文自己写着「It is not HTTP vs WebSocket」。
所以「开 WebSocket 能把过载降下来」这个假设，他引的证据不支持它。
能确认的只有他直接测到的那条：过载与账号强相关，部分个人 Plus 号长期 9%–21%，另一些号在相近流量下是 0%，所有请求的出口 IP 与出站身份都相同。2
开关本身在 v0.2.17 就有，按账号类型分两个字段。
OAuth 号读
openai_oauth_responses_websockets_v2_enabled，API Key 号读 openai_apikey_responses_websockets_v2_enabled；老字段 responses_websockets_v2_enabled 与 openai_ws_enabled 仍然兼容。11想让这件事有结论，只能自己 A/B：挑一个号开，同模型同时段比
server_is_overloaded 的频率。在那之前，别把整池一起切过去。
它也不会动那 400 条。没号可选的时候，换什么出站方式都一样。
六、CLIProxyAPI：一个文本块，把签名切成两组
14:15 开单：
gemini-api-key 账号打 Claude 的 /v1/messages。历史里只要有一条 assistant 消息把文本夹在两次工具调用之间，请求就回 400。12
报错原文是
Function call is missing a thought_signature in functionCall parts。Claude Code 在两段工具调用之间写一句话，就是这个形状；此后整段对话每次请求都失败。
他对着
generativelanguage.googleapis.com 量了四种形状。只有两个调用都签名的那一种通过；中间夹普通文本、或夹一个空文本，都回 400，夹 thought 才通过。12同一个请求走 Antigravity 正常，所以只有 Gemini API key 这条路中招。
本刊在 v8.0.40 上核了这段清理器，它每轮只记一个「见过第一个 functionCall」的标志。13
internal/signature/gemini_sanitize.go 第 74–112 行：第 75 行每轮初始化一次 firstFunctionCallSeen；第 105–108 行只在第一个 functionCall 上置真；第 110–112 行遇到没有签名的文本直接放行，这个标志照旧为真。(gemini_sanitize.go) 第二个调用因此被当成并行兄弟，签名被剥掉，Gemini 那边校验不过。
修法在 #6910：3 个文件 +24/−5，让每个文本之后的第一个调用都补上旁路签名，thought 不切断这个组。14
这张单 14:12 就提了，比 issue 早三分钟；base 是 dev，现在 open，mergeable 是 unstable。
在它进发行版之前只有绕：把夹在中间那句文本从历史里删掉，或者别让子代理写过渡句。
七、另外三条，一条都没进发行版
安全拦截的去向有两种。 #6915 处理
promptFeedback 拦截：OpenAI 出口报「流在任何 chunk 带 finish_reason 之前就断了」，等于截断。15 Claude 出口因为 promptFeedback.blockReason 已被算成结束信号，直接以空回复收尾。16上午那期我写过「安全拦截被报成断流只适用 v8.0.32 及更早」。那句说的是 Claude 出口这道守卫；OpenAI 出口到现在仍把它报成截断。17
两种都错，方向还相反：一个让你以为该重试，一个让你以为模型答了个空。
Home 模式的模型列表少两个字段。 #6914 报 Zed 1.25.2 接 Home 模式时，模型列表是空的。18
本刊核过：Home 模式那条 handler 每条模型只给 name、displayName、description、supportedGenerationMethods 四个键。19
internal/api/server_routes.go 第 1071–1086 行：返回的 map 只有四个键；结构体里带着 contextLength 与 maxCompletionTokens，这两个值一个都没写出去。(server_routes.go) 所以「CLIProxyAPI 缺 token 上限」这句，只在开了 Home 模式时成立。
这两张对应上午那期写的 #6897 与 #6898。
这个仓库的翻译层修复，只能等维护者自己落。
八、上游与额度
OpenAI 状态页全绿、没有活动事件；最近一条是支持系统的响应延迟，11:41 开、13:58 恢复，影响级别写的是 none。23
Anthropic 窗口内没有新事件，最近一条仍是 10 月 22 日 03:50 UTC 的连接器报错。
Google Cloud 最近一条停在 10 月 22 日 16:19 UTC 的 europe-west2。
额度两站还是各记各的。codex-reset 写今日 UTC 尚未重置，最近一次已验证全局重置是 10 月 22 日 17:10 UTC（北京今晨 01:10），累计 57 次、10 次 banked、节奏约每两天。24
它同时挂着一条实时承诺：Tibo 说到 10 月 23 日太平洋时间上午 10 点前落地，也就是北京 10 月 24 日凌晨 1 点。25
opentherank 把同一次重置记成 10 月 22 日 17:00 UTC，累计 65 次、中位间隔 3 天。25
差 10 分钟、差 8 次，两边都还没把它记成已验证。
另有一件跟安全有关、不改变上面任何行为：sub2api 主干 14:07 把 dompurify 升到 3.4.17，理由是两条 10 月 22 日发布的公告，一条 critical、一条 high，只改前端
package.json 与锁文件。26 v0.2.17 仍带旧版。九、今天的处置表
| 处境 | 今天做什么 | 依据 |
|---|---|---|
| 跑 v0.2.17、可调度号少于 3 个 | 这是最容易被放大的一档：模型冷却会把仅有的候选挡掉，先补号 | 判定 |
想让流内 server_error 也有同账号重试 | 池模式账号可在凭据里把 pool_mode_retry_status_codes 加进 502/503，默认只有 401/403/429 | 默认清单 |
| 怀疑过载是出站方式导致 | 单号开 openai_oauth_responses_websockets_v2_enabled 做 A/B；他引的那份实测支持的结论是别的 | 开关 |
| 等 sub2api 的池恢复 | #8311 已被作者自己关成 not_planned，改动只在分支上 | issue |
用 Claude Code 走 gemini-api-key | 别在两次工具调用之间插文本；#6910 未进发行版 | PR |
| 用 Zed 接 CLIProxyAPI 的 Gemini 端点 | 关掉 Home 模式，或手填 available_models | 字段 |
| 等 CLIProxyAPI 这批修复 | 六条全 open、都在 dev 之外，下一次发版前都不算数 | PR #6915 |
References
- 1sub2api #8311
github.com
- 230 分钟部署观察
github.com
- 3流内错误的归类
github.com
- 4换号错误体的构造
github.com
- 5默认同账号重试状态码
github.com
- 6错误映射表
github.com
- 7重试次数与间隔
github.com
- 8冷却分级
github.com
- 9运行期封锁判定
github.com
- 10codex-lb #2425
github.com
- 11开关的读取顺序
github.com
- 12CLIProxyAPI #6911
github.com
- 13签名清理器
github.com
- 14PR #6910
github.com
- 15PR #6915
github.com
- 16结束信号的四个来源
github.com
- 17截断那句话的出处
github.com
- 18CLIProxyAPI #6914
github.com
- 19Home 模式的条目格式
github.com
- 20注册表的 Gemini 分支
github.com
- 21PR #6913
github.com
- 22PR #6912
github.com
- 23OpenAI 状态页
status.openai.com
- 24codex-reset
codex-reset.com
- 25opentherank
opentherank.com
- 26主干提交 8286268
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.