sub2api 读请求体不设时限，CLIProxyAPI 插件每帧重拷整份请求
这一轮没有版本要升：sub2api 的读请求体缺一个时间上限、三种失败只回同一句 400，CLIProxyAPI 的插件在流式响应里每帧重拷整份请求体——两张补丁都还没合并，今天能动手的是前置代理那一层。
这一轮能成期的只有两张还没合并的补丁。sub2api 的
#8457 给读请求体补一个时间上限，CLIProxyAPI 的 #7131 让插件在流式响应里不必每帧都收到整份请求体。四个仓库这一轮都没有新版本，两家上游状态页全绿。
先看 sub2api 那条。走
/v1 网关的请求，body 在进 handler 之前要被整份读一遍。读不完的时候，这条连接上没有任何东西把它掐掉。慢速上传、传到一半客户端走了、body 本身畸形，三种情况回给客户端的都是同一句 400
Failed to read request body。sub2api：体积有上限，时间没有
两行注释把理由写在明处：不设
WriteTimeout，因为流式响应可能持续十几分钟；不设 ReadTimeout，因为大请求体可能需要较长时间读取。体积那一侧有闸。
globalMaxSize 取 cfg.Server.MaxRequestBodySize，配成 0 或负数时回落到 cfg.Gateway.MaxBodySize，大于 0 时套一层 http.MaxBytesHandler1。时间这一侧的空档落在中间件上。composite 分组（按规则把请求分给不同上游的那类分组）走的路上，
compositeTargetPlatformMiddleware 在调用 handler 之前，先用 ReadRequestBodyWithPrealloc 把整份 body 读进来2。分组模型白名单中间件同样处境。为了从 body 里取出客户端写的模型名，它也得先把整份请求读完3。
两处读失败时走同一段代码：状态 400，
invalid_request_error，文案 Failed to read request body。只有 http.MaxBytesError 被单独认出来，改成 413。后果分两层。一层在连接上：
ReadHeaderTimeout 只管请求头，头收完之后读 body 就没有 deadline 了，一个卡住的慢上传可以一直占着这条连接和它对应的 goroutine。另一层在日志里。真的超时、客户端中途断开、body 畸形，三者在回执与日志上长得一样，事后没法分开。
backend/internal/server/http.go 第 112–129 行：第 120 行设 ReadHeaderTimeout、第 122 行设 IdleTimeout，第 124 行注释写明不设 ReadTimeout；第 127 行往下是体积上限。1补丁给的东西
计时口径是两次读之间的等待。只要还在往里送字节，大上传不会被砍掉。
HTTP/1 与 HTTP/2 的待遇不同，原因写在注释里。HTTP/2 的 stream deadline 即使没有 pending 的 Read 也会触发，所以只在读的期间挂上，读一返回就清掉。
HTTP/1 的 deadline 只影响读，因此一直留到 body 读完。
net/http 写响应之前会自己排掉最多 256 KiB 没读完的 body，handler 拒了请求却没读完时，这段排水没有 deadline 会一直等下去。超时之后，那个已经过期的 deadline 会被保留。排水因此立刻失败，连接被关掉，不会再被拿去接下一个请求。
ResponseWriter 不支持 deadline 时（比如测试里用的 httptest），这层退化成无界。配置项是
server.request_body_idle_timeout，默认 60 秒，0 表示关闭。填超过 3600 会直接报 server.request_body_idle_timeout must be between 0 and 3600 seconds5。失败分类是补丁里最实用的一块6：
read_timeout回 408Timed out reading request bodyclient_disconnect回 499Client closed the connection before the request body was receivedmax_bytes仍然是 413truncated_body、decode_content_encoding、unsupported_content_encoding、transport、io_read仍然是 400Failed to read request body
判定顺序是先超时、后断连。HTTP/1 上读 deadline 到期本身也会取消 ctx，只看 ctx 会把超时误判成客户端走了。
断连的判据是错误链里出现
ECONNRESET、EPIPE、context.Canceled，或者 HTTP/2 报 client disconnected，或者请求的 ctx 已经取消。日志那边每次失败打一行，带
error_kind、status、protocol、content_encoding、content_length、chunked、bytes_read、read_ms。body 与错误原文都不写进日志。这张单现在开着，非 draft，mergeable 是 unstable，33 个文件 +965/−227，1 个提交，对着 main7。
唯一一条评论是作者自己补的。CI 里
frontend-security 检查在 main 上也失败，原因是 follow-redirects 1.16.1 带的 GHSA-mrwp-f3q8-3g9p，修复版在 1.16.2；base 与 head 的 frontend/pnpm-lock.yaml 是同一个 blob，与本 PR 无关8。今晚能做的四件
- 把读体超时压在更前面一层。nginx 的
client_body_timeout默认就是 60 秒，只在两次连续读之间计时，超时回 4089。这跟补丁想做的事是同一个口径，区别只是它在代理上，不在应用里。 - 让代理先缓冲整份 body。nginx 的 request buffering 默认开着，上游拿到的是本机到本机的快连接，慢的只剩客户端到代理那一段。
- 收紧
server.max_request_body_size。超大上传在体积闸上直接 413，走不到读不完那条路。 - 日志按「400 加长耗时」筛。补丁合并之前，耗时是唯一能把你和「body 畸形」分开的线索。
CLIProxyAPI：声明了响应翻译钩子的插件，每帧收三份请求体
TranslateStream 每处理一块响应，会依次过三处钩子：NormalizeResponseBefore、TranslateResponse、NormalizeResponseAfter10。插件宿主里，每一次这样的调用都要构造一个
ResponseTransformRequest，其中三个字段各自 bytes.Clone：OriginalRequest、TranslatedRequest、Body12。按作者描述，这两份请求体随后还要编码进 RPC 载荷。
internal/pluginhost/adapters_usage_translation.go 第 377–400 行：callResponseNormalizer 里第 393–395 行三行 bytes.Clone，第 403 行的 callResponseTranslator 同样三行。12作者给了一个量级：4 MB 上下文的请求、500 帧响应，大约 5 GB 的重复克隆与编码，host 进程 CPU 10% 以上，上下文越长越明显13。
影响面窄。只有声明了
ResponseTranslator、ResponseBeforeTranslator、ResponseAfterTranslator 的插件会走这条路，钩子为空时克隆根本不发生。没装这类插件的部署，这一条可以跳过。补丁的改法是给 ABI 加一个能力位。schema 版本从 9 升到 10，新增
SchemaVersionResponseTransformOmitRequestBody 与对应的 capability。新加的判断函数只在「流式、插件声明了这个能力、schema 大于等于 10」三条同时成立时，把两份请求体换成 nil14。
非流式照旧，schema 小于 10 的插件行为逐字节不变。测试覆盖三个钩子、能力位开与关、流式与非流式、schema 10 与 9 四种组合。
这张单也开着，非 draft，mergeable 是 clean，8 个文件 +177/−7，1 个提交，对着 dev13。它取代了当天的另一张中文单
#6859，那张在 10 点 56 分被关掉15。自动评审两次都没给出结论。第一次在开单十秒后记了
status: failed；作者 11 点 14 分回了一句 @codex review；11 点 15 分机器人回 Codex Review: Something went wrong. Try again later13。这条补丁现在没有任何第三方结论，读它只能自己看 diff。这一轮没有版本要升
| 仓库 | 当前版本 | 发布时间（北京） |
|---|---|---|
| CLIProxyAPI | v8.0.48 | 10 月 30 日 22:37 |
| sub2api | 0.2.19 | 10 月 28 日 18:16 |
| codex-proxy | v2.1.21 | 10 月 28 日 04:48 |
| codex2api | v3.1.2 | 10 月 28 日 04:40 |
窗口内四个仓库都没有新 tag，也没有主干提交。CLIProxyAPI 的 dev 头停在今天 10 点 04 分，比窗口起点早半小时20。sub2api 的 main 头停在 10 月 30 日 10 点 44 分21。
上游这边，OpenAI 状态页全绿，组件列表里没有降级的22。
Anthropic 也全绿，最近一条已恢复事件是 10 月 29 日凌晨的 Google Calendar 连接器故障，等级 minor，从 00:19 到 04:0523。Google Cloud 最近一次事故更新停在 10 月 28 日 08:38 的 europe-west2 多服务24。
Codex 的额度重置今天 UTC 还没发生。最近一次已验证的全局重置在北京时间 10 月 28 日 14:35，累计 61 次全局、10 次 banked（攒着没用的重置额度），节奏约每两天一次25。追踪站的结构化数据里，最新的官方信号停在 10 月 22 日，
signal.active 是假的26。Gemini 那边这轮核过了。官方开发者论坛的 Antigravity 区最新一条是 10 月 31 日 08:14，Gemini API 区最新一条是 10 月 31 日 04:12，都在窗口起点之前，两个分区窗口内 0 条新帖2728。
openai/codex 仓库窗口内新开 9 张单，编号 #58471 到 #58479。最接近额度的一条是
/fast 不改复用审批器的档位，其余是客户端 bug31。未闭合
#8457 会不会被维护者接手，那条 frontend-security 的依赖升级什么时候落；#7131 的自动评审能不能跑出结论。上游那张还没落地的重置承诺，官方最新一句停在 10 月 22 日，得等观测。
References
- 1v0.2.19 http.go 第 112–129 行
github.com
- 2v0.2.19 routes/gateway.go 第 548–575 行
github.com
- 3
- 4request_body_idle_timeout.go 第 1–40 行
github.com
- 5补丁分支 config.go 第 2100–2115 行
github.com
- 6PR #8457 全量补丁
patch-diff.githubusercontent.com
- 7sub2api PR #8457
github.com
- 8PR #8457 作者说明
github.com
- 9nginx ngx_http_core_module
nginx.org
- 10v8.0.48 registry.go 第 262–300 行
github.com
- 11
- 12
- 13CLIProxyAPI PR #7131
github.com
- 14PR #7131 全量补丁
patch-diff.githubusercontent.com
- 15CLIProxyAPI PR #6859
github.com
- 16CLIProxyAPI Releases
github.com
- 17sub2api Releases
github.com
- 18codex-proxy Releases
github.com
- 19codex2api Releases
github.com
- 20CLIProxyAPI dev 提交时间轴
github.com
- 21sub2api main 提交时间轴
github.com
- 22status.openai.com summary
status.openai.com
- 23status.anthropic.com incidents
status.anthropic.com
- 24Google Cloud Status incidents
status.cloud.google.com
- 25codex-reset.com
codex-reset.com
- 26codex-reset.com feed
codex-reset.com
- 27Antigravity 分区 RSS
discuss.ai.google.dev
- 28Gemini API 分区 RSS
discuss.ai.google.dev
- 29r/OpenAI
reddit.com
- 30r/ClaudeAI
reddit.com
- 31openai/codex 窗口内新开条目
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.