10/14 晚间续报：Claude 请求会卡在 TLS 握手不重试，v8.0.28 未修，先查空握手连接
补报 10 月 14 日 17:47 之后的增量：CLIProxyAPI 的 Claude 请求会卡在 TLS 握手且不触发重试，修复仍停在未合并的 PR；同一窗口还有 Antigravity 模型缺项，以及 sub2api 与 codex-proxy 各一条待合并的修复。
上一期通报停在 10 月 14 日 17:40（北京）。这一期补 17:47 之后出现的增量，窗口到 20:40。
四个小时里，本刊盯着的四个仓库都没有发新版本：CLIProxyAPI 最新仍是 v8.0.28，sub2api 仍是 v0.2.16，codex2api 仍是 v3.1.0，codex-proxy 的最新构建仍是 17:24 那个预发布。窗口内的新材料全在未合并的 PR 与 issue 里。
现在就做
- 给走 Claude 的链路加一道握手超时。 上游接受 TCP 连接却不回 TLS ClientHello 时，请求会一直挂着；
request-retry要等连接返回错误才开始计数，配了重试也用不上。1 - 用「发出 521 字节、收到 0 字节」这个特征去捞僵尸连接。 报告人在生产侧抓到七条这样的连接，存活 10.8 到 45.4 分钟，抓包确认发出去的那 521 字节就是 ClientHello。1
- Antigravity 的实例重启后，先确认
/v1/models里有gemini-4-argon系列。 重启后头几百毫秒的模型探测用的是内置的旧版本号，Google 按客户端版本门控新模型，这个版本拿不到这几个档位。23 - 同一个 OpenAI 用户加入的多个工作区，先走只带访问令牌的导入路径。 v0.2.16 上按用户标识匹配的那条路径会让后导入的工作区覆盖先导入的，最后只剩一条账号记录；修复 PR 已经开了，还没合并。45
- GLM Coding Plan 的用量概览，周期末尾那几个小时按重置倒计时判断。 管理端会把
5h与weekly两列的用量互换，识别方法是看倒计时：7 天的窗口不可能只剩 4 小时。6 - 管理端连着保存两次配置时，第二次可能丢。 第二次保存落在第一次的 reload 里，会被记成已经加载过，要等下一次文件变更才生效。7
上游：三家都没有新的额度或封号信号
Codex 的重置记录没有变化，最新一次仍是 10 月 13 日 13:06（北京）。8
Anthropic 的状态页在 10 月 14 日没有事件记录。9 10 月 7 日开始的 platform.claude.com 用量读数异常，在 10 月 14 日 02:00（北京）标记为已解决，期间 Claude API 请求不受影响。9
Google Cloud 的状态源在窗口内没有事件记录。10
这三家这一期都没有新的额度或封号信号。能落到处置动作上的，全在中转栈这一层。
CLIProxyAPI：Claude 请求会卡在握手里
CLIProxyAPI 当前最新版本是 10 月 14 日 08:41（北京）发布的 v8.0.28，这个窗口里没有后继版本。11
卡住的是握手，重试等不到
17:54（北京），有人开出了 issue #6615。现象是上游接受了 TCP 连接，却不回应 TLS ClientHello，一条普通的 Claude 推理请求就一直挂着。1
报告人把
request-retry 配成 3 也没用。重试只在连接返回错误之后才开始计数，握手既不完成也不报错，这一步永远轮不到。1表现是 Claude Code 一直在等当前这次调用，既拿不到及时的连接失败，也拿不到重试。连接堆积是附带症状。1
复现用的是一个只接受 CONNECT、读完 ClientHello 就不再发数据的假代理。7 秒后请求仍在 pending，假代理只看到一次握手尝试。1
claude tls: handshake upstream: EOF。v8.0.28 里还没有这个修复
Go 的
net/http 文档写明：一旦设置了 DialTLSContext，TLSHandshakeTimeout 就被忽略。流式请求的上下文又往往没有总体期限，或者期限很长，握手于是可以无限等下去。1218:44（北京），社区提交了修复 PR #6617。做法是给 Claude 传输层设 10 秒握手超时，并用
context.WithTimeout 给握手本身加期限；超时后立即关闭套接字并返回错误，让既有的重试策略接上。12
v8.0.28 里还没有这个修复。这一版的
utls_client.go 中，newClaudeCodeRoundTripper 依旧是自定义的 DialTLSContext 加一句裸的 HandshakeContext(ctx)，整个文件里没有握手超时。13要自己核，可以照报告人给的口径在连接表里捞一遍。同一个上游地址上，只发出 521 字节、一个字节都没收回、存活十分钟以上的连接，就是卡在握手里的那批。1
Antigravity 的模型列表会在重启后缺项
PR #6609（11:59 北京开出）写的是重启后的竞态。版本同步在后台协程里跑，账号注册与模型探测同时进行，探测先跑完时用的是内置的
2.9.1。2PR #6616（18:12 北京开出）报的是缓存过期这一路。过期检查看挂钟时间，刷新循环用单调时钟，主机睡过 6 小时再醒来时，内存里那份有效版本号会被丢掉。14
19:36（北京）开出的 issue #6619 补上了启动窗口这一段。版本更新器在账号文件加载之前异步启动，最初约 100 到 500 毫秒内被探测的账号会用旧版本号查模型，把不完整的列表缓存下来。3
另一条 PR #6598（10 月 14 日 04:12 开出，18:45 更新）说的是另一种缺项。模型探测不看账号里配的
user_agent，注册表按一种客户端身份建、生成请求按另一种身份发，只在其中一种身份目录里出现的模型会被本地过滤掉。15这几条都还没合并。重启过的实例，先去
/v1/models 里看一眼那三个档位在不在。2另外四条修改，都还开着
| 条目 | 时间（北京） | 内容与动作 |
|---|---|---|
| issue #6618 | 19:29 | 旧注册覆盖较新账号前缀。模型注册读到运行时快照后，如果账号前缀在期间被换成新的，旧注册收尾时仍会把旧前缀发布出去；v8.0.28 上的确定性复现显示 new=false old=true 16 |
| PR #6620 | 19:59 | reload 期间落地的配置保存会丢。第二次保存被记成已经加载过，两个快速的管理端保存会丢掉后一个；修法是只在文件前后一致时才记哈希，不一致就再跑一轮，最多三轮 7 |
| PR #6621 | 20:14 | Responses 的本地中断开关在终态事件之后仍然生效。response.completed 写完之后、上游流 EOF 之前收到的 response.interrupt，会给一个已经结束的回合补发 response.incomplete 17 |
| issue #6622 | 20:28 | 队列里的删除会摘掉期间重建的账号。删除动作在账号被重建之前就已观察，投递时不再核对当前状态，会把新账号和它注册的模型一起摘掉，直到下一次事件把它加回来 18 |
sub2api：两条修复都开了，都还没合并
sub2api 在这一窗口没有新版本，最新仍是 10 月 13 日 15:20（北京）发布的 v0.2.16。21
多工作区导入改按工作区隔离
根因是导入的身份键只用了
chatgpt_user_id，没有和工作区维度的 chatgpt_account_id 组合。同一个登录用户在个人 Plus 和多个 Team 里，chatgpt_user_id 相同，后导入的凭据就命中同一条记录并覆盖掉。4PR 的做法是把「
chatgpt_account_id 加 chatgpt_user_id」的组合键作为首选身份键，同时保留按账号键匹配的回退路径，用于同一工作区的账号更新和缺少用户标识的存量账号。4只带访问令牌的导入不受影响，一直按令牌指纹匹配，这次改动也保留了这条行为。要同时挂上几个工作区，先走这条路径。4
PR 作者说明管理端相关单测和定向检查都过了，仓库完整单测因为本地超时没能跑完。4
GLM Coding Plan 的用量窗口标反
GLM Coding Plan 把两条窗口都标成
CREDIT_LIMIT，走进降级路径后 unit 被丢掉，只剩按 nextResetTime 升序填空位。周窗口先重置的那几个小时，两档必然标反。6这个症状是间歇性的，只在「
CREDIT_LIMIT 且周窗口先于 5h 重置」时出现，也就是每个周期临尾的那几个小时。该函数从 v0.2.0 到 v0.2.16 逐字节没变，容易被当成随机抽风。6如果你按用量阈值做自动停调，这段时间先按重置倒计时判断。6
codex-proxy：面板少算 Antigravity 账号
codex-proxy 这一窗口没有新版本，最新仍是 10 月 14 日 17:24（北京）的预发布 v2.1.17-beta.1604624，稳定版是 10 月 13 日 15:25 的 v2.1.16。2223
19:17（北京），PR #870 开出，修的是面板数字。Antigravity 账号已经连上、卡片也在页面上，账号区却显示「暂无已连接的账户」和
0 / 0。24原因是
AccountList 只统计自己这一池 Codex 账号。空状态看的是它自己的账号数，标题和筛选计数也只算这条池子。24修法是把 Antigravity 池并进标题总数和「全部」筛选，并在存在 Antigravity 账号时不显示空状态。24
止血、恢复与防再犯
止血
- Claude 链路先加超时：把上游换到带连接与握手超时的出口，或者在客户端侧限制单次等待时间。112
- Antigravity 实例重启后确认模型列表，缺了就等版本同步完再探测。23
- 多工作区账号改走只带访问令牌的导入路径。4
恢复
卡住的连接不会自己报错，先按字节数把它们捞出来再处理。1
Antigravity 掉档位可以自证：拿同一个账号，用
2.23.0 的 User-Agent 请求一次 fetchAvailableModels，能拿到 gemini-4-argon 就说明是版本号掉回内置值造成的。2防再犯
| 制度 | 说明 |
|---|---|
| 连接存活巡检 | 定时捞出「已发出 ClientHello、零字节回包、存活超过十分钟」的上游连接 1 |
| 面板数字交叉核对 | 面板上的计数与用量窗口，和凭据文件、重置倒计时对一遍再用 624 |
| 改配置前快照 | CLIProxyAPI 的 config 与 auth 目录，在升级或批量改配置前先存一份 19 |
| 账号按凭证去重 | 账号识别与额度统计按工作区、按凭证，而不是按登录用户 4 |
号池与定价
GLM 的用量窗口标反会影响按阈值停调。把 14% 读成 90%，账号会提前从可调度池里出去。6
多工作区的覆盖行为决定号池结构。一个工作区一个账号这个结构，要等 PR #8088 合并之后才站得住。4
下一次通报等新的破坏性版本、明确的额度或封号信号，或者社区已验证的止血步骤。
References
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8Codex reset tracker
opentherank.com
- 9Claude Status
status.anthropic.com
- 10Google Cloud Service Health
status.cloud.google.com
- 11CLIProxyAPI v8.0.28 · Releases
github.com
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21Sub2API v0.2.16 · Releases
github.com
- 22
- 23codex-proxy v2.1.16 · Releases
github.com
- 24
- 25
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.