第 2 帧就交出去了：上游给 reasoning 项加了 encrypted_content，CLIProxyAPI 的 overload 换号从 10 月 18 日起失效
上游从 10 月 18 日起给 reasoning 项带上 encrypted_content，CLIProxyAPI 的 overload 换号因此失效，一周 1197 次拒绝全成截断的 200；这篇给出取证办法、三条处置路径和今晚该改的键。
如果你给 CLIProxyAPI 开了
upstream.codex.stream-bootstrap-buffering，这条保护从 10 月 18 日起就没有在工作。上游那几天开始给 reasoning 项的
response.output_item.added 带上 encrypted_content。代理把这帧读成「模型已经开始产出」，随即把流交给客户端。紧随其后的
server_is_overloaded 因此绕着换号逻辑过去了，落到客户端那片已经开始的 200 流里，变成一次半途断流。1发行版 v8.0.38 里那行判断还在，dev 分支也还没动。3
一周 1197 次，全变成了截断的 200
作者按
server_is_overloaded 帧的 sequence_number 把两周的日志切成两段。变化点在 10 月 18 日，那天他的实例还停在 v8.0.26，所以这是一次上游改动，发生在一周之前。1| 期间 | 落在第 2 帧 | 落在第 3 帧 | 落在第 4 帧及以后 |
|---|---|---|---|
| 10-11 至 10-14 | 3,092 | 265 | 24 |
| 10-18 至 10-21 | 0 | 1,192 | 5 |
第 2 帧是握手之后的
response.output_item.added。拒绝落在第 3 帧，意思是它会晚一帧才到，而那一帧已经在缓冲之外。旧的一组里，拒绝多数在第 2 帧到达，缓冲还握着流，代理能换号。新的一组里同一位置变成 0，几乎全部挪到第 3 帧，也就是流已经被交出去之后。
10-18 之后的 1,197 次拒绝，全部在 1 秒内以 HTTP 200 收尾，日志里没有第二次尝试。1
客户端那一侧对得上：Codex 的
logs_2.sqlite 里 232 条「stream closed before response.completed」警告，有 216 条落在代理 server_is_overloaded 行之后的 15 秒内。漏在哪一行
先说这个开关本来要挡什么。配置注释写得很明白：上游把
server_is_overloaded 塞在一条 HTTP 200 的流里送回来，而不在线上回 503；把开头的帧按住，下游响应头就没提交，代理还来得及换一张凭证重试。4按住哪些帧，是一张闭合名单：握手三帧、keepalive、以及内容还空的
*.added。名单之外的帧一律放行，注释里给了理由——认不出的帧可能已经在上游产生了副作用，按住它再换号就等于把副作用重放一遍。5
internal/runtime/executor/codex_executor_terminal.go 第 528–556 行，CLIProxyAPI v8.0.38，截于 2026-10-22 09:24（北京）。第 542–544 行是这次失效的入口。上游在
.added 帧上带的 encrypted_content 是一段约 1,336 字符的不透明状态，客户端还没看到任何东西。作者的说法是：按住这帧再换号，不会重放任何可见或产生副作用的内容，与空 reasoning 项没有区别。1流在哪一帧被交出去
流式执行器对每一帧先问一次「这帧能不能按住」。能按住的进缓冲，遇到第一帧按不住的，循环立刻跳出，把已经攒下的帧当作开头交给下游。6
internal/runtime/executor/codex_executor_stream.go 第 305–340 行，CLIProxyAPI v8.0.38。第 334–339 行是流被提交的那三行。另一条提前放行的路是预算：48 帧、1 MB 字节，或者
stream-bootstrap-timeout 到了时间上限。7 你现在撞上的是名单判据，预算还没轮到。流一旦交出去，同一条拒绝帧走另一条分支：它被包成状态错误，塞进流里发给下游，然后结束这次尝试。8
下游看到的就是 HTTP 200、收到几个握手帧、然后连接断掉。
补丁有了，版本还没有
补丁在报障人的评论里，改动很小：删掉 reasoning 分支里的
encrypted_content 早退，把「只有 encrypted_content 的 reasoning」从放行名单挪进持有名单，保留「有 encrypted_content 且 summary 非空」的放行，再加 SSE 与 websocket 两个用例。2他拿 v8.0.38（提交 0db19025）跑过：不打补丁时，新增的两个用例和
TestIsCodexBootstrapBufferableEvent 一起失败；打上之后通过，./internal/runtime/executor/...、./sdk/api/handlers/...、./sdk/cliproxy/auth/... 三组测试都过。这段改动在评论里，没进 PR，也没进 dev。dev 分支同名函数的第 542 行仍是旧的早退写法。3
这条链还连着 60 秒冷却
流内那条错误先被归一个状态码。
service_unavailable_error 不在专门的名单里，落进默认分支，成为 502。9502 在瞬时冷却名单里。这个冷却的取值规则是：上游给了 retry-after 就按它，没给就按配置值，配置为 0 时用 60 秒，配置为负时干脆不给冷却。10
于是每次 overload 顺手把这张凭证按进 60 秒冷却。作者在另一张单里把下游也量了：一个请求带重试走完所有候选凭证后，全池都在冷，接下来的请求几毫秒就被回 503，gin 访问日志只有一行
503 | 3ms，响应体里 error.code 是通用的 internal_server_error。11这类 503 也不进那条冷却日志，因为汇总只收额度冷却这一种原因。11
这条链今天仍然会触发。01:20 UTC（北京 09:20）上游又有人报：所有 Codex 项目同时回「模型容量已满」，换成 GPT-6 Astra 一样失败，而 5 小时与周额度都还剩着。12 容量拒绝仍在发生，缓冲失效的代价每天都在产生。
今晚怎么处置
第一步，确认你有没有踩在这上面。看配置里
upstream.codex.stream-bootstrap-buffering 是不是 true。它在 upstream: 下面的 codex: 段里，v8 之前的老写法 codex.stream-bootstrap-buffering 会迁到同一个位置，默认 false。13第二步，翻日志取证。搜索
bootstrap overload rejection 那一行（缓冲期命中拒绝时打的 debug 日志，后半句是 failing over，日志级别要开到 debug 才看得到）。610 月 18 日之后如果一次都没出现，而
server_is_overloaded 仍有，那就对上了。用 sequence_number 再核一遍更稳：分布落在第 3 帧就是这次的问题。第三步，三条路按代价排：
- 自己打补丁。 补丁就是评论里那段 diff，加上两个测试约几十行。构建之后分布会回到第 2 帧，overload 重新走换号。
- 等发版。 dev 没有、v8.0.38 没有，四仓窗口内也没有任何新版本，现在没有可升的东西。
- 只挡冷却这条连锁。 把
routing.cooldown.transient-error-cooldown-seconds设成负数，瞬时冷却就彻底关掉；设成 15 这类小值，冷却从 60 秒缩到 15 秒。1014 这条只管冷却时长，坏凭证被重新选中的间隔会变短，代价按你的池子掂量。
第四步，把监控口径换一下。overload 按
sequence_number 计数；毫秒级的 503 单独算一类，那是本地拒绝，记在上游错误里会把容量账算歪。窗口里另外两条
#6853 第四笔提交。 今天 01:05 UTC，作者 eaxeax 往这张单上又推了一笔
fix(auth): track Vertex service account identity，把 Vertex 的 service account 与 project 变化纳入 CredentialsChanged 判定。整单现在 4 笔提交、4 个文件、+482，状态 open、可合并、未合并。15它修的是文件快照覆盖运行时状态。v8.0.38 里，快照应用回写凭证时，只有
credential_quota 这一种冷却会被搬回，其余运行状态照抄快照。16
sdk/cliproxy/auth/conductor_lifecycle.go 第 396–419 行，CLIProxyAPI v8.0.38。第 407–418 行是唯一一段「把旧冷却搬回来」的代码。落到运维上：auth 目录被外部改写（同步盘、脚本重生成）的站，一张刚因为瞬时错误被按住的凭证，会在下一次快照应用时被放回可选池。这一条和上面的 overload 失效叠在同一晚，冷却是最容易白丢的那部分状态。
sub2api 的构建修好了。 #8275 在 00:44 UTC（北京 08:44）合并：Dockerfile 的默认 Go 镜像从 1.27.2 换成 1.27.3。17
原因是 main 的
backend/go.mod 已经要求 go 1.27.3，而镜像默认还是 1.27.2，不带 --build-arg 从 main 构建会在编译阶段停下。18 现在 Dockerfile 已是 1.27.3；手里还是旧代码的，构建时加 --build-arg GOLANG_IMAGE=golang:1.27.3-alpine。四仓与上游现状
四仓窗口内零新版本：CLIProxyAPI v8.0.38、sub2api v0.2.17、codex-proxy v2.1.20-beta.0543eaa、codex2api v3.1.1。19202122
主干时间：CLIProxyAPI main 停在 10-21 15:04 UTC，dev 停在 19:41 UTC（还是 #6843 那笔，那张单今天仍开着、标签是 Fixed）。23 sub2api 的 main 因为 #8275 挪到 10-22 00:44 UTC；codex-proxy 的 main 仍在 10-18，codex2api 的 main 仍在 10-20。
窗口扫描：CLIProxyAPI 只有 #6856 与 #6853 两张；sub2api 是 #8275 与一张被顶起的旧帖；codex-proxy、codex2api 都是 0 条。
上游状态全绿。OpenAI 全组件正常，最近一条历史事件是 FedRAMP 那条，10-21 19:34 UTC 已恢复。24 Claude 状态页今日无事故，最近一条仍是 Fable 5 的降级，10-21 20:29 UTC 恢复。25 Google Cloud 仍停在 10-20 那条 europe-west2。26
重置信号那边没变：今天 UTC 还没重置，最近一次已验证的全局重置在 43 小时前（北京 10 月 20 日 14:33），累计 56 次、10 张存着，24 小时概率 22%、48 小时 39%，页面计算时刻是 10-22 01:19 UTC。27 另一家站的口径仍是 64 次、中位间隔 3.1 天。28
今天要做的三件事
- 查
stream-bootstrap-buffering开没开。开着，就把「overload 会自动换号」这句从你的容量预案里删掉，直到补丁进版本。 - 翻这四天的日志，数
server_is_overloaded帧的sequence_number。落在第 3 帧的占多数，就是这一条，动手打补丁或把transient-error-cooldown-seconds调小。 - 把毫秒级 503 单独拉一条曲线，那一类记的是本地拒绝次数。
References
- 1
- 2补丁与测试结果（#6856 评论）
github.com
- 3
- 4config_types.go 第 233–251 行（v8.0.38）
github.com
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13config.example.yaml 第 391 行（v8.0.38）
github.com
- 14config.example.yaml 第 220–222 行（v8.0.38）
github.com
- 15
- 16
- 17
- 18backend/go.mod（main）
github.com
- 19CLIProxyAPI releases
github.com
- 20sub2api releases
github.com
- 21codex-proxy releases
github.com
- 22codex2api releases
github.com
- 23
- 24OpenAI status summary
status.openai.com
- 25Claude Status
status.anthropic.com
- 26Google Cloud incidents
status.cloud.google.com
- 27codex-reset.com
codex-reset.com
- 28opentherank codex reset tracker
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.