10/15 晚间快报：Codex 凭证的过载 502 被原样递给客户端，换凭证的开关默认没开
补报 10 月 15 日 17:28 到 18:05（北京）：CLIProxyAPI 上 Codex 凭证撞上上游过载会以 502 直接落到客户端，换凭证的那个开关默认关着；同一窗口还登记了一条被标为不予采纳的插件鉴权缺口、一条插件刷新提案，以及 Codex 重置追踪两站口径的合拢。
这一期覆盖 10 月 15 日 17:28 到 18:05（北京），承接上一期的发稿时间。
四个仓库这一窗口都没有出新版本，主干也没有新提交。素材集中在 CLIProxyAPI：一条新的 Codex 凭证 502 报障，以及它背后一个默认关着的开关。1
现在就做
- 在反向代理后面部署的，同时把
upstream.codex.stream-bootstrap-timeout设成"20s"。 开了缓冲以后，响应头要等上游开始生成才提交；Cloudflare 的 100 秒、Nginx 默认的 60 秒读超时会先咬人。3 - 号池只有一两个账号的，别把期望放在换号上。 这次报障用的是两个不同的 Plus 账号，两条日志撞的是同一个过载。池子里没有别的凭证，换无可换。1
CLIProxyAPI #6654：Codex 凭证配 GPT 模型频繁 502
报障在 17:36 提交，现在开着、还没有人回复。报障人写的是两份 Plus 账号配置的 Codex 凭证在
gpt-6-luna 上频繁回 502。1日志两条落在 17:34:19 同一秒，一条 2.949 秒、一条 3.628 秒，格式都是
conductor_execution.go:1967 打出来的 502。1两条用的凭证文件不同，分别是
codex-5db8ebc3-1@outlook.com-plus.json 和 codex-2e7b34f8-2@outlook.com-plus.json。上游返回的错误体里，
type 是 service_unavailable_error，code 是 server_is_overloaded，文案是 Our servers are currently overloaded. Please try again later.。1第一条还多带一个字段
headers.x-retry-metadata: NO_MORE_RETRY，第二条没有这个字段。本刊在 v8.0.29 的整包源码里搜过
x-retry-metadata 和 NO_MORE_RETRY，非测试文件一处都没有命中。这个版本不解析这个响应头，只把它连同错误体一起透传。报障人补了一条观察：用 Codex 客户端直接登录不出现这个现象，日本时区下午尤其频繁。他同时问了三件事——是 OpenAI 那边的问题、是这个项目给 token 设了上限、还是这个项目有冷却期。1
为什么默认会变成 502
v8.0.29 把
service_unavailable_error 和 server_is_overloaded 明确列进了「可以换一条凭证再试」的过载类错误，和它们同列的还有 rate_limit_exceeded。5这个判定只在一个地方被调用：开着 bootstrap 缓冲的那条流式路径。缓冲关掉时，代码根本走不到这里。6
配置项的注释给出了这样设计的理由：上游在线上回的是 200，过载拒答被塞在这个 200 的流里一起发下来。4
先把生成开始前的那几帧押住，响应头就不会提前提交，这次尝试才有机会换一条凭证重来。代价写在同一条注释里：响应头被推迟到上游开始生成，慢思考的轮次会多等几个心跳间隔。4
关着的时候，这句过载被原样翻给客户端，状态码走映射表的兜底分支，也就是 502。报障日志里那个 502 正是这个兜底分支。7
开着的时候，executor 在响应头还没提交前就放弃这次尝试，并把状态码报成 503，调度器于是可以拿另一条凭证重试。5
internal/runtime/executor/codex_executor_terminal.go 第 601–634 行。第 607 行的函数把这种情况上报成 503；第 615 行的函数决定哪些上游错误算得过载，第 626 行就是 service_unavailable_error 与 server_is_overloaded 那一条判据。5开关的写法有三种，v8 的配置迁移把老路径都认了下来。当前版本的正规位置是
upstream.codex.stream-bootstrap-buffering，codex.stream-bootstrap-buffering 与 oauth.providers.codex.stream-bootstrap-buffering 两种老写法仍然会被读进去。8同一个开关也管着 WebSocket 那条传输路径，两边的判定逻辑是同一份。9
缓冲只在预算之内生效。 押住的帧数用满 48 帧、字节数用满 1 MB，或者超过你设的
stream-bootstrap-timeout，流就放行，后面的过载一样原样下发。4客户端不带
stream 的非流式请求走的是另一条执行路径，那条路上遇到终局错误直接返回，没有换号的余地。10502 还是 503：先判断是自己还是上游
日志里记 502，说明这次过载被原样交给了客户端，调度器没有换凭证。
记 503，说明这次尝试被作废、调度器换过凭证；如果最后还是失败，意味着池子里的凭证都被上游拒了。两个状态码对应两条路径，看一眼数字就知道自己处在哪一边。5
上游那个
server_is_overloaded 是 OpenAI 自己的错误分类，文案也是它自己的原话。1日本时区下午高发、用 Codex 客户端直连不出现，这两条观察指向同一个方向：容量问题出在上游。中转站这边能做的，是别让它以 502 的形式落进下游统计。
窗口内的其余登记
#6651 被标记为不予采纳。 这条在 17:41 关闭，状态是
NOT_PLANNED，页面上没有写理由。11它报的是插件拿不到客户端地址与 Host、resource 路由没有管理鉴权。少了这两样，插件就没法自己判断「只允许本机访问」。
#6650 收到维护者回复。 17:29 的回复说，经 OpenAI 转换的请求会忽略
redacted_thinking，以 Claude 格式转发到 Kimi 上游时，历史里的那个块会被原样转发。12块里装的是 Anthropic 的加密载荷，跨厂商转发时只能把它移除。维护者要的最小复现信息是 CPA 版本、客户端与入口端点、Kimi 模型名、上游报错原文、块类型样例。
#6653 是一条提案。 它在 17:24 提交，落在上一期窗口的末尾，本刊没有报过。提案要求给原生插件加一套「宿主机管理的惰性 token 刷新」：凭证过期或快到 60 秒余量时，在第一条带认证的请求上刷新，账号闲置时不去轮换。13
作者点出了阻塞点：过期的 access token 在凭证选择阶段就被拒掉，请求到不了插件执行器。把刷新逻辑写进
Execute 或者 ExecuteStream 都行不通。版本与上游
| 组件 | 最新发行版 | 发行时间（北京） | 本期相关改动是否已含 |
|---|---|---|---|
| sub2api | v0.2.16 | 10 月 13 日 15:20 | 本期无相关改动 |
| CLIProxyAPI | v8.0.29 | 10 月 15 日 00:24 | 本期说的配置项在这个版本里就已存在 |
| codex-proxy | v2.1.17 | 10 月 14 日 23:59 | 否，本窗口无相关改动 |
| codex2api | v3.1.0 | 10 月 13 日 04:00 | 否，本窗口无相关改动 |
官方状态页。 Anthropic 全部组件正常，今天到目前没有事件。18
Google Cloud 的事件源里，最近一条仍是 10 月 8 日开始、10 月 9 日结束的 Cloud Storage 上传与写入延迟。19
OpenAI 状态页仍是 Partial System Degradation，唯一在办事件还是 10 月 15 日 01:00 那条 Compliance API 成本数据延迟，窗口内没有新更新。20
上游三家这一窗口都没有额度或封号类的新事件。
重置追踪。 codex-reset.com 首页这一窗口改了口径，现在写的是 Today 6:13 AM UTC 官宣了一次已验证的全局重置，也就是北京 14:13，并标着「4 hours ago」。21
同一个站的时间线把 10 月 15 日标成 verified reset，距上一次 2.0 天，计数器 0d 03:44。前几期首页写的是「今天到目前为止没有重置」，与站内模型侧的 06:13 UTC 互相矛盾，这一窗口两边合上了。22
opentherank 记的最近一次重置仍是 10 月 15 日 12:55（北京），中位间隔 3.1 天。两站对时刻的记录差一小时十八分钟。23
社区侧。 r/OpenAI 最新一条停在 17:25，比本期窗口早两分钟，内容是账号被封的申诉，与额度无关。24
r/GeminiAI 最新一条停在 17:18，也在本期窗口之前。25
r/ClaudeAI 窗口内有一条新帖，17:47 发出，内容是作品展示，不涉及额度与风控。26
OpenAI 开发者社区 Codex 分区窗口内没有新话题，最新一条停在 17:26——有人提议让 Plus 用户把 5% 的每周额度换成一次 5 小时额度补充，也落在本期窗口之前。27
linux.do 原站这一窗口仍返回 403，晚报镜像最新一期还是 10 月 14 日的第 006 期。28
References
- 1Issue #6654
github.com
- 2Issue #8104
github.com
- 3config.example.yaml 第 379–399 行
github.com
- 4config_types.go 第 188–214 行
github.com
- 5codex_executor_terminal.go 第 601–634 行
github.com
- 6codex_executor_stream.go 第 237–250 行
github.com
- 7codex_executor_terminal.go 第 178–203 行
github.com
- 8config_v8.go 第 36–38 行
github.com
- 9codex_websockets_stream.go 第 245–250 行
github.com
- 10codex_executor_execute.go 第 159–166 行
github.com
- 11Issue #6651
github.com
- 12Issue #6650
github.com
- 13Issue #6653
github.com
- 14CLIProxyAPI v8.0.29
github.com
- 15Sub2API 0.2.16
github.com
- 16codex-proxy v2.1.17
github.com
- 17codex2api v3.1.0
github.com
- 18Claude Status
status.anthropic.com
- 19Google Cloud Service Health
status.cloud.google.com
- 20OpenAI Status
status.openai.com
- 21Codex Reset
codex-reset.com
- 22Codex Reset History
codex-reset.com
- 23OpenTheRank
opentherank.com
- 24r/OpenAI
reddit.com
- 25r/GeminiAI
reddit.com
- 26r/ClaudeAI
reddit.com
- 27Codex · OpenAI Developer Community
community.openai.com
- 28linux.do 晚报 · 板块汇总
linuxdo.club
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.