代理直连、WS 单次拨号、interaction 终局：CLIProxyAPI 早上把三张单判成 not planned
CLIProxyAPI 早上把三张单判成 not planned：代理配错时直连、WS 握手只拨一次、interaction 终局不算终局，都被认定是有意行为；四张修复 PR 仍开，唯一留着的 #7029 只挂了 pending。同一夜里 gpt-5.5 只从 dev 与远端目录删掉，发行版内置四档仍在，一行排除名单仍是要做的。
北京时间 10-27 早上 08:03 到 08:32，CLIProxyAPI 的维护者连关三张报障单。三张全判成 not planned，理由都是同一类：现在的行为是有意的1。
这三张单的报障人是同一个人：eaxeax。四张对应的修复 PR——#7030、#7031、#7032、#7034——仍开在仓库里，一张没合。
唯一没被关的 #7029 只打了一个 pending 标签2。
对运维的意义很直接：把止血押在「上游迟早会合这个补丁」上，今天行不通。同一夜还有两条与目录、模型元数据有关的动作，放在后面。
三张单，三种「有意如此」
interaction.completed 之后挂断被记成 499，最终判为 Closed as not planned。报障人留言里的统计是，自 10-21 起他开了 20 张单、15 张 PR。1eaxeax 在 #7024 里把处境写清楚了：自 10-21 起开了 20 张单和 15 张 PR，15 张 PR 至今一张未合1。
维护者 luispater 在关这张单时把规则写了下来。这个仓库几乎全部单由他一个人处理。按他的算法，独立修一张比评审一张外部 PR 省三到五倍 token、五到八倍时间。
因此，除非修复简单到看一眼就能评审，一般不合外部 PR1。这句话解释了下面三条判定，也解释了那 15 张 PR 的处境。
代理不可用就直连（#7026）
#7026 说的是：配了却构造不出来的代理——畸形 URL、没有 host、
ftp:// 这种 scheme——被跳过，请求直接出门3。维护者的判定是这就是设计。回落是项目的有意行为，需要全部流量走代理的运维应该自己在网络层强制3。
代码里对应的是
proxy_helpers.go。buildProxyTransport 返回 nil 之后只打一条 Debug 日志，就继续往 context 的 RoundTripper 或默认 client 走4。对号站意味着出口 IP 从你的代理换成了机房 IP。这正是封号与限额判定的输入。
今天能做的是把出口钉死在网络层：让网关进程所在的 uid 只能连到代理地址，其余 REJECT。uid 与代理地址按自己环境替换，别照抄。
验证不用猜。在代理侧看连接计数是否为零，或在同机请求一个回显 IP 的服务，确认真实出口。
握手只拨一次（#7027）
#7027 说的是 Codex 的 WebSocket 在 HTTP Upgrade 阶段遇到 EOF 就直接失败，没有第二次机会5。
conductor_cooldown.go 第 2068–2094 行：第 2070–2071 行的注释写明这类错误「按 request-retry 重试、不给凭证上冷却」，第 2086 行把 io.EOF 与 io.ErrUnexpectedEOF 判为瞬时传输错误。6这句判定在代码里站得住。
isRequestRetryRoundError 把瞬时传输错误算进重试轮，与 403、408、429、500、502、503、504 同一条路7。所以你要查的不是补丁，是配置。
routing.retry.request-retry 默认 3，设成 0 就真的没有第二轮8。凭证只有一张也不影响重试轮。维护者举例说，一张可用凭证配 retry 3，初始尝试之后最多还有三轮。
边界也要说清：这条只覆盖拨号阶段。上游建连之后掉线是另一张单，#7033 仍开着。
interaction.completed 不算终局（#7024）
维护者的判定是客户端责任：正确的客户端应该继续读到 EOF 再断1。
response.completed、response.incomplete、response.done、message_stop，第 25–34 行看 finish_reason，两处都没有 interaction.completed。9落点在 Gemini 执行器。每送出一条 chunk 就置一次
terminalDelivered；函数退出时如果 ctx 已取消、终局却从没送出去，就走 PublishFailure 而不是 Publish10。ctx 取消对应的状态码是 499，
client_error.go 里那个 nginx 风格的常量11。影响有两层。成功率统计里会多出一批 499；客户端其实已经拿到完整回答，账单上却是一条失败。
今天能做的是让客户端读到
done 再断，或在中间层不要收到 interaction.completed 就立刻收流。唯一没被关的那张（#7029）
08:38:44，#7029 被打上 pending；六分钟前那三张同类单都关了，唯独这张没关、也没回复2。
区别在责任侧。#7029 是 Home 模式下网关自己把已完成的凭证选择释放掉，导致下一轮换连接重发——问题在网关这一侧。
对应补丁 #7034 仍开着。它进发行版之前，WS 会话别指望靠
previous_response_id 续接。gpt-5.5：只在两个源移除
#7035 在 08:42:11 判 completed。维护者写的是，
gpt-5.5 已从当前目录的 free、team、plus、pro 四张清单里删除12。这句话对两个源成立，对发行版不成立。
| 源 | 四档里还有 gpt-5.5 | 说明 |
|---|---|---|
| v8.0.44 内置目录 | 有，4/4 | 正在跑的发行版就是这份13 |
| 主干 main 内置 | 有，4/4 | 与发行版同源14 |
| dev 内置 | 无 | 07:16:40 那笔提交一次删掉四处15 |
| 远端镜像 | 无 | 10-18 已删，两份镜像同源16 |
gpt-5.5，第 3406–3413 行给出 id、display_name、version 与 description。13后果与上一期一样。内置目录还列着它时，ChatGPT 账号下的 gpt-5.5 请求会拿回 400，然后按模型不支持写 12 小时冷却17。
只有三种实例会一直读内置：启动带
--local-model、把 models.codex-catalog 指到本地文件，或者根本拉不到远端目录。自查看管理端。
GET /v8/management/credentials 里每条凭证的 cooldowns，reason 是 model_not_supported、remaining 约 43200，就是中了。注意优先级。凭证文件里自己的
excluded_models 非空会整体覆盖这份全局名单，不合并。另外一提，客户端侧目录里那条 gpt-5.5 模板仍随发行版走，还带着
upgrade 指向 gpt-6.1-sol、retirement_at 为 2026-10-14T19:00:00Z；dev 把它换成了 Sol 的元数据副本19。模板按 slug 套到清单里出现的模型上，所以它不改变上面的结论。sub2api：Terra 适配的第二版
GPT-6.1 Terra 的适配单来了第二版。#8365 于 08:29:14 开出，28 文件 +680/−46、mergeable clean，基于第一版 #8364 并保留它原有的提交20。
它指出第一版的错：把 API 模型页的参数套到了 Codex 目录上。结果是 Codex 客户端看到默认档位 medium、没有 ultra，上下文退回 272k，base instructions 还是 GPT-5.5 那套20。
configuredCodexFallbackContext 在第 332 行，第 448–449 行把它同时写进 ContextWindow 与 MaxContextWindow。23这张单还补了三处。Terra 不接受 minimal 档位，兼容路径改回 400；兼容路径补上派生的
prompt_cache_key；OAuth 与 setup-token 的 Terra 请求免收 272k 长上下文附加费。现状是两张都开着，#8364 与 #8365 谁先合谁生效24。v0.2.18 仍认不出 gpt-6.1-terra，这一点上一期已核过。
合了之后核对两个数就够：窗口 500k/872k、档位 low 到 ultra。
接下来要做的四件事
- 把出口钉在网络层。代理配错时网关会直连，这是有意行为，不会替你改。
- 核
routing.retry.request-retry与可用凭证数。设成 0，WS 握手 EOF 就没有第二次机会。 - 把
gpt-5.5写进oauth.excluded-models.codex，或确认实例已经从远端目录刷新过。 - 客户端别在
interaction.completed后立刻收流；WS 会话暂不依赖previous_response_id。
版本与上游
四仓窗口内零新版本。CLIProxyAPI 仍是 v8.0.44（10-26 23:49 发布，dev 头停在 10-27 07:16）25，sub2api v0.2.18、codex-proxy v2.1.21-beta、codex2api v3.1.1 均未动。
codex-proxy 与 codex2api 窗口内零条目，sub2api 只有一张 PR 与两条旧帖被顶起。
上游三家状态页窗口内没有新事件。OpenAI 全绿，最近一次是 10-27 02:19–02:30 的 Ads POST 错误率26；Claude 全绿，最近是 10-25 16:17 起的 Fable 5.1 报错27；GCP 最新仍是 10-23 00:19 的 europe-west228。
重置侧同样安静。最新真人帖停在 10-27 06:01，signal 未激活29。
References
- 1#7024 Gemini Interactions 挂断被记 499
github.com
- 2#7029 Home 凭证没被钉住
github.com
- 3#7026
github.com
- 4proxy_helpers.go
github.com
- 5#7027
github.com
- 6conductor_cooldown.go
github.com
- 7conductor_selection.go
github.com
- 8config.example.yaml routing.retry
github.com
- 9gemini_stream_terminal.go
github.com
- 10gemini_executor.go
github.com
- 11client_error.go
github.com
- 12#7035
github.com
- 13v8.0.44 models.json
github.com
- 14main models.json
github.com
- 15dev models.json
github.com
- 16远端目录
raw.githubusercontent.com
- 17conductor_cooldown.go 第 1041–1049 行
github.com
- 18config.example.yaml 排除名单
github.com
- 19codex_client_models.json
github.com
- 20#8365
github.com
- 21openai/codex 126a0ee9
github.com
- 22gpt-6.1-terra 模型页
developers.openai.com
- 23openai_codex_models_service.go
github.com
- 24#8364
github.com
- 25v8.0.44
github.com
- 26status.openai.com
status.openai.com
- 27status.claude.com
status.claude.com
- 28status.cloud.google.com
status.cloud.google.com
- 29codex-reset
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.