15 秒静默被判不修：三条缓解全否，另一处空转已在 dev 修掉
维护者把「Claude 上游静默 15 秒被 RST」判成不修，并逐条否掉了 h2、首块缓冲、静默计时三条缓解；同一小时 dev 修掉了只读 Codex 凭据的刷新空转，v8.0.50 里还没有。
这一小时最重要的是判定，不是版本。
上一期把「Claude 上游静默 15 秒被掐断」列为待修。21:44（北京），维护者把那张单关成了 not planned，并逐条写清了三个缓解方案为什么都不做 1。
同一小时里，dev 修掉了另一处更隐蔽的空转：只读的 Codex 凭据让刷新调度器原地打转、把 CPU 烧起来。这条修复不在 v8.0.50 里。
一、那 15 秒不在 CPA 的框里
先把时间线钉住：20:35 开单，21:44:30 关闭，中间 69 分钟。关闭理由一句话，「15 秒静默重置属于外部网络与边缘行为，不是 CLIProxyAPI 的 bug」 2。
维护者没有只说一句不修。他把报障人提的三条缓解逐条驳了一遍，这四条口径才是今晚要读的东西。
口径一：本机没有那道闸。 CPA 不为上游请求设置任何连接建立之后的读超时或空闲超时。
维护者的原话是这一句：
helps.NewUtlsHTTPClient(ctx, e.cfg, auth, 0)，第四个参数就是 0。也就是说，等待本身没有任何本地上限。口径二：为什么不能换成 h2。 上一期原样转述过这条建议，这次被明确否掉，理由分两层。
第一层是指纹。官方 Claude Code CLI 在推理面协商的是 http/1.1，并发送一组大小写混合、顺序固定的头。换 h2 会同时改掉 TLS 的 ALPN 指纹和 HTTP 的线上表示，因为 HPACK 会把头名全部小写。
第二层更硬：Codex 那条路本来就跑在 h2 上（Chrome 的 uTLS 指纹），在报障人这条网络路径上一样在 15 秒被打断。所以问题不在协议版本。
claude_executor_request.go 第 1522–1545 行：claudeWireHeaderCasing 只列了五个「被 Go 规范化后会变」的头；紧随的注释写明 ALPN 是 http/1.1、头名因此不被 HPACK 小写，大小写才是可观测的 3口径三：把首块压住也不行。 报障人建议先缓冲到「第一个完整内容块 + 一小段宽限」，让重置落回可重试的路径。
维护者给了三个不做的理由：这会给流式回合凭空加 15–20 秒首字延迟；它保护不到后续的静默（比如前导文本之后的工具参数生成）；重放那些会确定性停顿的提示词，会导致上游 token 重复计费，他引了自己那张老单 4。
口径四：不加静默计时日志，并顺手解释了一行日志。 为了跨厂商执行日志的简洁一致，不做逐块空闲计时。
他还点了一件事：报障人贴的
[claude_executor_stream.go:349] response body close error 只是 Go 的 gzip.Reader.Close() 在返回扫描器已经报过的那个粘性错误。那不是第二处故障，别顺着它查。所以今晚的动作要改。 这一条从「等修」变成「客户端兜」。
本地没有开关能救它，三个看着像的东西都不管这件事：
requests.tls-handshake-timeout-seconds 只约束握手（默认 0，即不设）6；requests.streaming.keepalive-seconds 只发下行心跳、默认关；upstream.codex.stream-bootstrap-* 只压首块之前那一段。还能动的只有两处：按「首块前 / 首块后」给你的断连分桶，和客户端的续跑钩子（
StopFailure，matcher 填 server_error）。二、dev 修掉了刷新空转
22:29，PR #7143 合进 dev：5 个文件、+292/−14，合并提交
24f9744，合并人是维护者本人 7。这两笔修复今天凌晨 02:52 就写好了，到 22:29 才合。v8.0.50 不含它们——这一版 21:32:42 就发出去了，比合并早 57 分钟。
病根是两条路撞在一起。 一条只有 access token、没有 refresh token 的 Codex 凭据，照样会进「按到期时间刷新」的通用队列。
本地执行器没有可换的东西，只能把没变的 auth 原样返回、错误给
nil。于是日志不断打出 refreshed codex <id>, <nil>，看着像刷新成功，其实一个字节都没换。本来管理器会记一个 30 秒的「刷新无效」退避。但被禁用的凭据在凭据串没变时，生命周期更新会把上一次的 pending 标记盖回新的退避上；任务完成又把 pending 清掉，于是立刻又到期。
症状是 CPU 与刷屏。 那行
refreshed 是 Debug 级别，默认日志里看不到，所以多数人先看到的是 CPU。自查方式很直接：把日志开到 debug，
grep 'refreshed codex' 再筛 , <nil>，看它是不是每隔几十秒就出一条。修法是把这类凭据挡住，并把刷新产出留住。 新增的
codexAutoRefreshUnavailable 在三种情况下放行——Home 模式、带自定义运行时刷新评估器、有 refresh token 或可刷新的 SIWC 分区；其余不进自动刷新队列。这套判定套在四个入口：重建队列、脏更新、到期处理、待办任务重查。刷新结束后，时间戳与退避也不再被旧标记覆盖。
sdk/cliproxy/auth/conductor_refresh.go 第 117–135 行：codexAutoRefreshUnavailable 的四个判定与 shouldRefresh 的接入点；第 126 行的注释写明「本地 Codex 执行器只读 refresh_token」 8
conductor_lifecycle.go 第 506–519 行：凭据串没变时，LastRefreshedAt、NextRefreshAfter、RefreshFailures 三行把刷新产出整个盖回旧值；修复把这一段收进了 mode != updateModeRefresh 的条件里 9谁该现在动。 跑 dev 或自编译、号池里又有 access-only Codex 凭据的，换到含
24f9744 的构建，这一条就没了。只跑 v8.0.50 的，先按上面的 grep 确认有没有在转。在转的话，等下一版，或者自己编一份。
三、一个插件挂多个入口，面板分不出来
22:03 有人开了一条新单：一个插件注册多个 OAuth 登录入口之后，控制台渲染不出来 10。
源头是上一版才进的功能。
a8dbebab（#7126）让一个插件能注册多条登录入口，GET /v0/management/plugins 现在会同时给出单数的 oauth_provider 和复数的 oauth_providers: ["a", "b"] 11。够路由，不够渲染。RPC 侧只有 identifier 与 identifiers 这样的裸键，没有展示名。
图标更彻底：
pluginapi.Metadata.Logo 整个插件只有一个，管理接口把它原样抄进每条记录。于是同一个插件的两个入口，在面板上是两张同名同图的卡片。
internal/api/handlers/management/plugins.go 第 128–132 行：OAuthProviders 已经按数组下发，但 Logo 仍取自插件的单一 Metadata.Logo，每个入口拿到的是同一张图 12复数字段确实已经通了，只是下游没人消费：管理控制台仍然只解析
oauth_provider，一张插件卡只画一个入口。把数组读进去，也只会得到两张同名同图的卡片。同一小时 dev 还落了另一件插件的事，别混。 提交
ce39bc62（Closes #7110，7 文件 +375/−58）给插件商店加了 locale 规范化与分类透传 13。那是商店条目的多语言，不是单个插件内部多入口的命名与图标。两件事都在插件这一层，但改的不是一处。
对你的影响：按插件 id 与 provider 名配凭证不会错；按面板上的名字或图标选会错，尤其是国际站与国内站这种两个入口同一家厂商的场景。
四、还没合的三张补丁
- #7165（20:10 开，3 文件 +81/−2）：凭据去重身份加上 connection-pool。不修的话，两条只差池设置的 Gemini 凭据会被判成同一条，第二条被静默丢掉
- #7166（20:14 开）：handler panic 之后 request logging 仍要执行 Finalize，否则那条请求的日志连同流式 writer 一起泄漏
- #7168（20:21 开）：运行时改
oauth.auth-dir之后，watcher 与 fsnotify 跟着换目录。22:23 那一轮自动评审在提交71d218b上仍判了未解决发现
三张都还开着，v8.0.50 一张都不含。
sub2api 那边这一小时没有新动静：
#8473（受限管理员密钥读统计接口 403）维护者仍未回应，开放补丁里也没有对应的修法。五、行情
| 仓库 | 当前版本 | 发布时间（北京） | 本窗口 |
|---|---|---|---|
| CLIProxyAPI | v8.0.50 | 11-01 21:32 | 无新版本；dev 领先 5 个提交 |
| sub2api | 0.2.19 | 10-28 18:16 | 无 |
| codex-proxy | v2.1.21 | 10-28 04:33 | 无 |
| codex2api | v3.1.2 | 10-28 04:39 | 无 |
发布时间取自各仓库发行页的
published_at 14。dev 比 v8.0.50 多五个提交：#7143 带进来的两笔修复与一笔文档、插件商店 locale 一笔，加上合并提交本身。两版 config.example.yaml 逐字节相同，升级不用改配置。重置这一侧今天 UTC 没有全局重置。最近一次已验证的仍是 10 月 28 日 06:35（UTC），累计 61 次、10 枚 banked，
signal.active 为假 18。今晚的顺序
- 15 秒这条从「等修」改成「客户端兜」：按首块前后分桶，再决定从换号还是从会话续跑补
- 自查刷新空转：debug 日志 grep
refreshed codex后跟<nil>；在转的就把构建换到含24f9744的那份 - 多入口插件按 id 配，别按面板上的名字与图标配
References
- 1CPA issue #7169
github.com
- 2#7169 关闭说明
github.com
- 3claude_executor_request.go
github.com
- 4#5545 重复计费
github.com
- 5#6534
github.com
- 6v8.0.50 config.example.yaml
github.com
- 7PR #7143
github.com
- 8dev conductor_refresh.go
github.com
- 9v8.0.50 conductor_lifecycle.go
github.com
- 10CPA issue #7170
github.com
- 11#7126
github.com
- 12plugins.go
github.com
- 13ce39bc62
github.com
- 14CLIProxyAPI releases
github.com
- 15OpenAI status
status.openai.com
- 16Anthropic status
status.anthropic.com
- 17GCP incidents
status.cloud.google.com
- 18codex-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.