首帧不来时网关会一直等：CLIProxyAPI 缺的这道上限，补丁还开在别人的 fork 上
CLIProxyAPI 在首帧迟迟不来时没有任何上限，请求会一直挂到客户端自己放弃；新开的两张单说清了原因并带来一版补丁，同一窗口另有三张修单被作者在 24 秒里一起关掉。
北京 08:53 到发稿，一个半小时左右。四个仓库没有发新版，CLIProxyAPI 的主干也没有新提交。
窗口里只有三件事值得现在看：一张新单说清了「首帧不来时网关在等谁」，并配了一版补丁；三张修单被同一个作者在 24 秒里一起关掉，一件也没进主干；sub2api 合了一张 92 个文件的管理密钥大单，却没有任何发行版带上它。
一、首帧不来时，没有任何东西在计时
先看症状：客户端报超时，网关日志里这次尝试挂满了整个窗口，一个字节也没写出去。 1
上游慢和上游消失，是两件事。前者是第一个 token 出得晚，后者是第一个字节根本不来——连接断在响应头之后、后端卡住、队列一直不排。 1
心跳救不了后者。
streaming.keepalive-seconds 只在响应流已经提交之后才发心跳，而首字节之前这段路还没有提交。 1本来该兜底的是
streaming.bootstrap-retries：首字节之前失败，就丢掉这次尝试、换一张凭证重来，默认 0 即关闭。 2它接不住沉默，因为它的触发条件是「首字节之前报错」。
sdk/cliproxy/auth/conductor_stream.go 第 91–125 行：第 108 行的 ctx.Done() 与第 123 行的「读到非空 payload」是仅有的两个出口，循环里没有计时器。上游不说话，这两个出口都不会出现。请求就挂在那里，直到客户端自己放弃。
补丁 #6931 加的正是这道缺口：新增
streaming.bootstrap-timeout，默认 0，仍然无界。 4到期时取消这一次尝试的 context。
bootstrap-retries 还有预算，就再发一次；预算用完，就在写出任何 SSE 字节之前回 504，并把上限写进错误里。 4作者在单里给了三组端到端读数：默认无界时，上游 8 秒不写字节，客户端超时；
bootstrap-timeout: 3s 配一次重试，6.00 秒回 504，上游正好收到两次请求；上游停一次再服务，3.0 秒回 200 并带真实 SSE。 4三处边界要记住：插件执行器那条路不经过这段代码；首帧之后仍然无界；Home 模式的重试预算被强制为零。 4
这张单还引用了一条旧账：#5545 已经关成「上游行为」。所以这版补丁只管网关这一侧的等待——变成有上限、可重试、能说清楚，上游的沉默留给上游。 1
二、今天能动的四组旋钮
补丁还开着，今天能动的只有现有配置。 5
| 旋钮 | 它能解决什么 | 它管不到什么 |
|---|---|---|
streaming.keepalive-seconds 与 send-keepalive-before-ft | 前者在响应流提交后发注释心跳，后者让首字节之前也发 2 | 心跳只让客户端继续等，结束不了这次尝试；不认注释的客户端照样断 |
streaming.bootstrap-retries | 首字节前就报错时换号重来 2 | 沉默不报错，永远不触发 |
routing.retry.request-retry 与 max-retry-interval | 换号轮次、两轮之间最多等 30 秒 6 | 同样要有失败信号才会动 |
routing.cooldown.transient-error-cooldown-seconds | 408、500、502 一类瞬时错误的冷却长短，写 0 保持 60 秒、写 -1 关闭 7 | 与首帧等待无关 |
internal/config/sdk_config.go 第 353–367 行：StreamingConfig 只有心跳间隔、首字节前心跳、重试次数三项，没有任何与时间上限有关的字段。自查分三步。第一步，找出客户端报超时的那几分钟，看网关有没有对应的尝试，它持续了多久。第二步，看这次尝试有没有写出过任何字节；一个字节都没写，多半就是这一节说的情况。第三步，看客户端的空闲判定是按 data 事件重置，还是也认
: keep-alive 注释——只认 data 的客户端，心跳帮不上忙。三、零输出 interrupted 被判成上游失败
走 Codex 这条路时，还有一处会把「上游其实没坏」判成故障。
IsCodexTerminalEmptyIncomplete 的条件很具体：事件是 response.incomplete、没有任何非空的文本或工具参数增量、没有 output item、output_tokens 恰好是 0。 8四条全中，它就当成上游静默中断，返回 502，文案是
stream error: upstream terminated with incomplete empty response (0 tokens)，并标成请求级错误、不换号。 9问题出在
incomplete_details.reason：判定函数不看它。上游明确说「我被打断了」，只要输出是零，也照判。
internal/runtime/executor/codex_websockets_stream.go 第 430–445 行：第 432 行调用空响应判定，第 437 行以 terminal_empty_incomplete 为原因作废这条上游连接，第 438 行再清掉活动连接。连接被作废，下一轮就得重建。你看到的是「这一轮空回复之后，下一轮明显慢了」，上游那边则一切正常。
这个判定在六处被调用，WebSocket 与 HTTP 各三条路径。 8
这张单在窗口内被关掉了，没有合并。 11
四、三张单在 24 秒里一起被关
主干与 dev 的头仍停在 10-24 02:18:56，也就是 v8.0.41 那一笔，三件都没有落地。 14
关掉的是三件不同的事。#6878 是上一节那处零输出误判，3 个文件、+55/−9。 11
#6875 让会话亲和与 LCP 状态跨重启存活，18 个文件、+1754/−15；按单里的说法，它原本要把未过期的绑定从
<auth-dir>/.runtime/session-affinity.cache 恢复回来。 12#6874 加「同一凭证、同一实际模型上的额外尝试」，配置键是
routing.retry.same-upstream-retry，默认 0，28 个文件、+1711/−82，关单时的 mergeable 是 dirty。 13三张都没有关单说明。 11
#6875 欠的那件事，对已经打开会话亲和的实例有成本。v8.0.41 的会话亲和默认关闭；打开后 TTL 一小时、子代理默认继承、重绑策略
any，但这些绑定只活在内存里。 15进程一重启，绑定就没了。重启后的头几条会话会重新选号，上游侧的 prompt 缓存要重建，表现为缓存命中率下降与首字变慢。
今天能做的是挑重启时机：避开批量任务中途，重启后先别把长会话切过去。
五、sub2api 合了一张 92 个文件的管理密钥大单
sub2api 这边方向相反：一张大单真的合了。
#8319 在北京 10:12:38 合进 main，92 个文件、+9054/−131，新增迁移 247。 16
它要做的事很具体：把一个全站通吃的管理员密钥，换成可以按操作和资源范围拆开的多枚密钥。 16
几条边界值得记住。
未登记的操作与接口默认拒绝，新增接口不会自动继承权限。 17
一条规则内部是「与」：操作在名单里、账户类型在名单里、平台为空或命中其中一项、已分组账户至少命中一个所选分组。账户类型给空列表，表示没有账户操作权限，而不是所有类型。 17
多条规则之间是「或」，但不同规则里的账户类型与分组不能拼起来授权。 17
共享账户仍然是整号：命中其中一个授权分组，就可能允许对这个账号执行已授权操作，改凭证、改状态、刷新或删除会影响所有使用它的分组。 17
docs/admin-api-keys.md 第 17–32 行：第 19–24 行是一条规则内部的四个必需条件，第 26 行说明规则之间是「或」且不能拼接授权，第 30 行写明共享账户仍是一个账户资源。完整密钥只在创建或轮换的那一次响应里出现，库里只保存摘要，撤销记录留给审计。 18
今天升不上去：v0.2.18 的迁移目录到 246 为止，247 只出现在主干预览里。 19
所以如果你正打算把管理密钥交给推送脚本或自动化，这几天能做的还是老一套：按网络收掉暴露面，给脚本单独一个出口，别把全权密钥写进别人的 CI。
六、窗口里的其余
四仓版本没变，主干只有 sub2api 动了。
| 仓库 | 当前版本 | 发布（北京） | 本窗口动作 |
|---|---|---|---|
| sub2api | v0.2.18 20 | 10-23 15:44 | #8319 合并，迁移 247 |
| CLIProxyAPI | v8.0.41 21 | 10-24 02:25 | 三张单被作者关掉；#6930、#6931 新开 |
| codex-proxy | v2.1.20 22 | 10-23 03:56 | 零条目 |
| codex2api | v3.1.1 23 | 10-17 05:42 | 零条目 |
Google Cloud 仍是八条，最近一条还是 10-22 的 europe-west2，没有新事件。 26
Codex 重置两站口径这次都读到了，数字并不一致。codex-reset 说按 UTC 算的今天还没有重置，最近一次已验证的全局重置是北京 10-23 01:10，距今 33 小时，累计 57 次、10 次 banked、节奏约每两天。 27
opentherank 记 65 次、中位间隔 3 天、最长 68 天，页面停在 10-23。 28
10-23 那条「明天上午十点前落地」的承诺，到发稿仍未落地：站点仍记今天没有重置，信号区挂的还是 10-22 那条。 29
上游仓库窗口内新开的一批单清一色是桌面端、连接与权限类，没有能核对到额度的。
七、还没闭合的
#6931 会不会被合。它挂着
Closes #6930，0 条评论，维护者还没表态。 4被关掉的三张会不会有人重新提交。三张同出一个 fork，关单没有人解释。 11
#8319 会进哪一版。v0.2.18 是 10-23 15:44 发的，这张单在它之后十小时才合。 16
上游的沉默有没有人认账。#5545 已经关成「上游行为」，之后的每一次首帧不来，都只能靠网关这一侧自己设上限。 1
References
- 1issue 6930：给首帧等待加上限
github.com
- 2流式配置的三个字段
github.com
- 3v8.0.41 的 readStreamBootstrap
github.com
- 4PR 6931：给首帧等待加上限
github.com
- 5v8.0.41 的流式配置样例
github.com
- 6v8.0.41 的重试配置
github.com
- 7v8.0.41 的冷却配置
github.com
- 8v8.0.41 的空响应判定
github.com
- 9这个错误怎么造出来
github.com
- 10WS 路径上的作废
github.com
- 11PR 6878：保留零输出的中断响应
github.com
- 12PR 6875：会话亲和跨重启存活
github.com
- 13PR 6874：同一上游重试
github.com
- 14CLIProxyAPI 主干提交时间轴
github.com
- 15v8.0.41 的会话亲和配置
github.com
- 16PR 8319：按操作与资源范围授权的管理员密钥
github.com
- 17受限管理员密钥文档
github.com
- 18迁移 247 的表结构
github.com
- 19v0.2.18 的迁移目录
github.com
- 20v0.2.18
github.com
- 21v8.0.41
github.com
- 22v2.1.20
github.com
- 23v3.1.1
github.com
- 24OpenAI 状态汇总
status.openai.com
- 25Claude 状态汇总
status.anthropic.com
- 26Google Cloud 状态
status.cloud.google.com
- 27codex-reset 首页
codex-reset.com
- 28opentherank
opentherank.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.