每条流式 Claude 请求都在重开一条连接，v8.0.53 就带着，补丁还没合
v8.0.53 里每条流式 Claude 请求都会重开一条上游连接：流末两处 break 加上一个只 Close 不排空的收尾，补丁还开在 dev，附带一分钟自查法与打补丁时要避开的 defer 顺序坑。
v8.0.53 上，
stream: true 的 Claude 请求一条一条地重开上游连接。报障人在代理与
api.anthropic.com 之间抓了包：连续四条请求（非流式、非流式、流式、流式），修之前用掉两条连接，修之后只有一条。1原因不在 Anthropic，在代理自己：看到
message_stop 就跳出读循环，剩下的响应体还没读完就关掉。net/http 只有把 body 读到 EOF 才把连接还回空闲池，没读完就 Close 等于真关一条连接。所以今晚这条路是断的：升级拿不到修复，只能自己打补丁，或者不动。
一屏判定
| 你在监控里看到的 | 在 v8.0.53 上它意味着什么 | 代价落在哪里 | 今晚能做的 |
|---|---|---|---|
| 流式请求一条一条新建上游连接 | 不是限流、不是账号问题，是收尾没读完 body | 每条请求一次 TCP + TLS 握手 | 自己打补丁，或不动 |
| 并发一高连接数就线性涨 | 同上，连接数跟 QPS 同阶 | 文件描述符、出口 NAT 端口、握手 CPU | 同上，先算 FD 与端口余量 |
| 非流式请求连接是复用的 | 符合预期，缺陷只在 stream: true | 无 | 不用管 |
| 切换到 Codex 上游就正常了 | 那边按设计每请求一条连接，不受这条影响 | 无 | 不用管 |
根因：两处跳出，收尾只有 Close
图里的这个 goroutine 是每条流式请求的读循环。2
defer close(out) 先注册，第 350–355 行才注册关 body 的 defer，两者之间没有任何一次读。仓库 router-for-me/CLIProxyAPI，tag v8.0.53，文件 internal/runtime/executor/claude_executor_stream.go 第 343–358 行。2第一件事是
defer close(out)，第二件才是关 body 的 defer。关之前，没有"把剩下读完"这一步。整份 v8.0.53 的
internal/runtime/executor 生产代码里，io.Discard 零命中——只有测试文件里出现过。这条链路上从来没写过排空。跳出点在两个地方，直通分支和翻译分支各一处，用的是同一句条件。3
if upstreamCompleted || upstreamStreamErr != nil { break } 是 Claude 直通分支，翻译分支第 530–531 行是同一句。仓库 router-for-me/CLIProxyAPI，tag v8.0.53，同文件第 423–438 行。4upstreamCompleted 在收到 message_stop 那一刻就置真。语义结束了，HTTP 响应没结束。分块传输的终止符
0\r\n\r\n 还在路上；走 gzip 的话，后面还有一个 trailer。两者都没读，defer 就跑完了。同一个账号上，非流式请求是正常的：那条路径一路
io.ReadAll(decodedBody) 读到 EOF，再 Close。5所以它不是配置问题，也不是账号问题，是同一个人写的两条路径差别。
为什么偏偏是 Claude
Claude Code 全程流式。对这类前端来说，等于每条请求都付一次握手。
更关键的是终止符的到达方式：
message_stop 事件与 chunked 终止符通常分两段到，代理在第一段就跳出了。1报障人写测试时特意让服务端把终止符押后——"像真实 API 那样在后一段发送"，这样一次单纯的 Close 永远放不掉连接。1
换成 Codex / ChatGPT 就不一样：那边按设计每请求一条专用连接，这条缺陷不会额外增加什么。1
换句话说：这条缺陷挑的是"通过 HTTP 复用连接"的那些上游，Anthropic 正好是主力。
对方的实测，两个量级
四条请求，
stream 依次是 false、false、true、true。修之前：前两条非流式共用一条连接；第三条沿用同一条，但在 27 字节的结束块到达后 1 毫秒，代理自己发
close_notify + FIN；第四条另开一条。1修之后：四条走同一条连接，而且之后还开着。
真实 Claude Code 流量随后单连接跑了约 17 分钟、约 6 MB 上游数据，直到 Cloudflare 按 400 秒空闲超时从服务端关掉。1
这组数字的意义不是"偶尔多一条连接"。是一条流一条连接，稳态下连接数与请求速率同阶。
自己量，一分钟
在代理机上开一个终端，先记基线：
ss -tan state established '( dport = :443 )' | wc -l
tcpdump -n -i any 'tcp[tcpflags] & tcp-syn != 0 and host api.anthropic.com'然后驱动一批流式请求（20 条足够），再数一遍。
判据：N 条流式请求带来大约 N 个新 SYN、或大约 N 条常驻连接，就是中了。
容易误判的地方：如果上游把终止符和最后一块塞进同一段到达，可能看不出差别。多打几十条再数。
这也是 Claude 特别容易被忽略的原因——症状是"连接数有点高"，而不是某个报错。
补丁的形状，以及那道 P2
补丁只有七行，插在同一个 defer 里、Close 之前。6
io.Copy(io.Discard, io.LimitReader(httpResp.Body, 64<<10))，外面套一层 ctx.Err() == nil。来自 PR 7237 头分支 mschirrmeister/CLIProxyAPI 的 fix/claude-stream-keepalive，文件 internal/runtime/executor/claude_executor_stream.go 第 346–363 行。6if ctx.Err() == nil {
_, _ = io.Copy(io.Discard, io.LimitReader(httpResp.Body, 64<<10))
}有界 64 KiB，客户端取消时跳过，不引入新超时。最后这条不是随手写的：仓库规范第 61 行明写，超时只允许出现在取凭证阶段，连接建立之后不得对任何网络行为设超时。7
一处改动同时覆盖直通与翻译两条分支，因为两处都落回同一个 defer。
但别照抄这个顺序。自动评审提了一条 P2，到现在还没被回应。8
理由是 Go 的 defer 后进先出：
defer close(out) 注册在前，排空的 defer 注册在后，所以排空先跑、close(out) 后跑。按仓库规范又不能拿超时去解决连接后的读。所以正确的形状只有两种。
一是把
defer close(out) 挪到排空 defer 之后再注册，让它先跑；二是让通道关闭与排空彻底解耦，排空放去别的 goroutine。这条对读者的意义很直接：自己打补丁时，别只抄那七行。
顺带自查：OpenAI 兼容通道是同一个形状
报障人写明只审了 Claude 执行器，"其他执行器未审计"。1
本刊顺着看了 OpenAI 兼容通道，跳出方式一模一样。9
scanLoop:，第 572–575 行遇到空行时调 processFrame()，返回真就 break scanLoop，收尾靠函数级 defer httpResp.Body.Close()，中间同样没有排空。仓库 router-for-me/CLIProxyAPI，tag v8.0.53，文件 internal/runtime/executor/openai_compat_executor.go 第 560–580 行。9结构相同，但会不会真丢连接，取决于
[DONE] 与最后一块是否落在同一次读里。本刊没有实测这一段，只能算自查项。要验的话，用上一节那两条命令，不必先读代码。
版本位与其余三仓
这个窗口里，四个仓库都没有新版本。
也就是说：主干没有未发版的排空补丁，
dev 上也没有。codex2api：
v3.1.2 还是 10-28 那一版，窗口内零提交。13另有一条值得知道，但不用为它升级：
#7175（muse-* 的 client_attestation_denied）11-01 就以 completed 关了，维护者在这个窗口里补了一句"已在 dev 由 #7113 修"。14本刊核了对应的那段：
EnsureMetaMuseToolNamespaceDoc 在 v8.0.52 和 v8.0.53 的 meta_executor_execute.go 里都已经在了。手上是这两版的人，不用动。上游
OpenAI 状态页全绿，组件里没有一个非 operational；最近一次事故还是文件上传那个，已经恢复。15
Anthropic 状态页同样全绿，这个窗口内没有新事件。16
Google Cloud 还是 10-28 那条多产品事故，没有新进展。17
Codex 的重置信号安静：
signal.active 为 false，最近一条被标成"新帖"的其实是雷达区的闲聊，不是重置承诺。18最近一次已验证的全局重置还是 10-28。今晚不必为了额度去改什么。
今晚按顺序做几件
第一件，先量。两条命令，五分钟。没中就不用往下看——这条缺陷不值得凭感觉动手。
第二件，中了但今晚不能停机。什么都不改，先算余量：连接数与请求速率同阶，看你的 FD 上限和出口 NAT 端口够不够。
第三件，能改代码。自己 cherry-pick 那七行，但把
defer close(out) 的注册顺序一起调，或者让排空离开这个 goroutine。只抄七行的话，长连接上会多一个挂死的可能。第四件，不想自己打补丁。等合并。补丁的目标分支是
dev，合了还要等下一次 tag；现在 dev 上也没有，别以为切过去就有了。第五件，顺手看一眼别的执行器。尤其你在跑 OpenAI 兼容通道，那边是同一个形状。
References
- 1
- 2
- 3
- 4
- 5
- 6CLIProxyAPI PR 7237 改动文件
github.com
- 7CLIProxyAPI AGENTS.md 第 61 行
github.com
- 8PR 7237 的 P2 评审意见
github.com
- 9
- 10CLIProxyAPI v8.0.53 发行页
github.com
- 11codex-proxy 发行列表
github.com
- 12sub2api 发行列表
github.com
- 13codex2api 发行列表
github.com
- 14CLIProxyAPI issue 7175
github.com
- 15OpenAI 状态页
status.openai.com
- 16Claude 状态页
status.claude.com
- 17Google Cloud 状态页
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.