一个请求体被读四遍：CLIProxyAPI 插件鉴权把 8 GB 机器打进 OOM
CLIProxyAPI 的插件鉴权对每个请求整包读体再复制，8 GB 机器 20 分钟被内核杀了 5 次；同一窗口 sub2api 两张补丁并进主干却没进版本，上期那张 Claude Code 指纹补丁被作者自己关掉。
今天 17:40，CLIProxyAPI 收到一张新单：只要装了声明前端鉴权的插件，网关就会对每个进来的请求整包读一遍请求体并复制。1
报障人跑在一台 8 GB 内存、没有 swap 的机器上，插件叫 credit-manager。他贴出的内核日志从 10:42:49 到 11:02:14，20 分钟里杀了 5 次，每次常驻内存 5.7–6.1 GB。1
这张单报了两个版本：v8.0.29 与 v8.0.45。今天 dev 分支上那两行代码还在原处，仓库里暂时没有对应的修复补丁。1
窗口里另外三件都在今天下午：sub2api 的 #8390 与 #8395 先后并进主干，两张都没进 v0.2.18；上期那张把 Claude Code 指纹对齐到 2.1.311 的 #8394，17:12 被作者自己关掉、没有合并。
一个请求体走过四道手
那个函数一路读到 EOF。
adapters_interceptors.go 第 422–423 行取出原始 body，io.ReadAll 一次读完；第 434 行把 r.Body 换成 bytes.NewReader(body)，这份缓冲留在请求里，给后面的 handler 再读一遍。
internal/pluginhost/adapters_interceptors.go 第 418–436 行，v8.0.45：第 423 行的 io.ReadAll 没有长度上限，第 434 行把读到的整包换回请求体。3第二份在第 253 行。构造交给插件的请求时，
Body: bytes.Clone(body) 把整包再复制一遍。2
internal/pluginhost/adapters_auth.go 第 246–256 行，v8.0.45：第 248 行把控制权交给插件，第 253 行用 bytes.Clone 把整包复制进 Body 字段。2第三、第四份出在序列化与跨语言边界上。
FrontendAuthRequest.Body 声明成 []byte，json.Marshal 会把它 base64 编码一次，宿主再用 C.CBytes 把这段字节交给插件的 C ABI。报障人把这几步算成「每个请求四份全尺寸拷贝」，与代码对得上：原始缓冲、
bytes.Clone 的副本、base64 字符串、C 堆各一份。1同一条链上另有一处对照。请求拦截器那边有两个开关，
RequestInterceptorOmitBodyBefore 与 RequestInterceptorOmitBodyAfter，插件声明后宿主不必把 body 交过去；这两个字段从 v8.0.44 起就在协议里。4前端鉴权这一侧没有对应字段。
FrontendAuthRequest 的 Body 无条件填满，插件只能连 body 一起收下。5
sdk/pluginapi/types.go 第 458–474 行，v8.0.45：第 470 行的 Body []byte 是无条件字段，结构体里没有「不要 body」的开关。5为什么每个请求都要付这笔
Manager.Authenticate 按注册顺序遍历提供者，第一个返回成功的就是结果，返回「不处理」的继续往下走。6插件声明前端鉴权后，
RegisterFrontendAuthProviders 把它的适配器注册进这条链，之后每个进来的请求都先经过它。插件若声明 exclusive，这条链上只剩它一个。代价与鉴权结果无关。报障人用 8 MiB 的合成请求体打干净实例，8 个请求全部回 401、一个都没到上游，常驻内存照样单调上涨：v8.0.29 从 32 MB 到 207 MB，v8.0.45 从 34 MB 到 191 MB。1
OOM 前那次 pprof 采样（456 MB 存活）里三个热点很清楚：
io.ReadAll 206 MB、bytes.growSlice 136 MB、handlers.cloneBytes 103 MB。1判自己的实例会不会中，只需看一件事：有没有装声明了 frontend auth provider 的插件。只有装了这类插件，才会付这笔开销。
今晚能做的三件事
第二，把
server.max-request-body-bytes 从默认的 0 改成有限的数。配置样例第 35 行写的就是 0，含义是不限。7这个值要高于你真实的最大请求体。报障人的 Codex Desktop 单个请求到 18.5 MB，设小了正常请求会被挡在鉴权这一步。
第三，如果你的插件只拿 header 做鉴权，评估改用本地 API key，把插件从鉴权链上摘下来。
降版本救不了：报障人在 v8.0.29 上实测到同样的问题。1
sub2api 两张补丁并进主干，没进版本
17:41:30，#8390 合并进 main。这张单 13:50 开出时本刊写过：渠道页只提交 anthropic 维度，后端整块替换
features_config，于是任何一次界面保存都会抹掉 openai、command_code 等平台的 web search 模拟。8main 上现在多了
mergeWebSearchEmulationDimensions：请求带这个键就按平台合并、缺失的维度继承现值，完全不带就整键继承，显式传空对象或 null 才清空。9v0.2.18 里没有这个函数，整个文件 0 命中。10
今天从发行版升上去，抹维度这件事仍然在；想要它，得等下一个版本或自己构建 main。
当分组里每个可调度的 Gemini 账号都配了
model_mapping 时，列表返回各账号映射键的并集，详情按同一来源判断，未覆盖的模型回 404，也不再请求上游。只要有一个账号没配映射，就退回原来的选号透传。
backend/internal/service/gemini_models_endpoints.go 第 27–54 行，sub2api main：第 40–45 行逐步收集每个账号的映射键，第 41–42 行遇到没配映射的账号直接返回空，读侧因此退回选号透传。12第二件是默认模型列表。前端
geminiModels、geminicli.DefaultModels、gemini.DefaultModels() 三处统一成 17 个现役模型，移除 2.0/2.5 系列与 gemini-3-pro-preview；连接测试的默认模型从 gemini-2.0-flash 改成 gemini-3.5-flash。11这条变化会落到读者的白名单上：升级后新建 Gemini API Key 或 Vertex 服务账号，预填的是新列表（含 3.6 / 3.7 / 3.8-flash），2.x 那一套已从默认值里移出。Google One 老账号仍用旧列表。11
v0.2.18 同样没有
DeclaredModelIDs，这张单的改动也只在 main 上。13上期那条指纹线断了，另一家反着走
#8394 是上期的主线。它把
cc_entrypoint 默认改成 sdk-cli、补五个 anthropic-beta、把 Stainless 版本号与 Runtime 版本对齐真机、给 body 补 safeguards 块。1417:12:59，作者 znl1087 把它关掉，
merged 为 false。14关闭前只有一条评论，来自 CLA 机器人：它要求作者在 PR 里回帖签字，同时提示这次提交用的邮箱没有关联 GitHub 账号，签不了。14
指纹这条线今天在 codex2api 那边往另一个方向动。17:38 开的 #839 把 OAuth 刷新与后台授权码交换的 HTTP 客户端从标准库
crypto/tls 换成 Chrome uTLS。15同一张单还把
.env.example 与 docker-compose.pgredis2004.yml 的 CODEX_TRANSPORT_MODE 默认值改成 utls_chrome，用 compose 部署的人升级后传输模式跟着变。15它还改了设备画像的默认值：
STABILIZE_DEVICE_PROFILE 未设置时从关变成开，显式写 false 才关。codex2api 的 main 上，这一项要读到环境变量等于真值才打开稳定化。16
proxy/device_profile.go 第 101–119 行，codex2api main：第 116 行只在 STABILIZE_DEVICE_PROFILE 等于 true 时打开设备画像稳定化，未设置即为关；#839 直接把这一行的语义改成默认开。16sub2api 另有一张 17:14 开的 #8397，改 4 行、删 21 行，仍在评审。它修的是 OAuth 刷新响应不带新 refresh token 时把旧的丢掉，以及账号缺 refresh token 时直接返回即将过期的 access token。17
这两条都会在 access token 过期后表现成 401，报障单点名的正是 OpenAI 账号测活时的间歇 401。
版本状态
四仓本窗口都没有发版。当前版本：CLIProxyAPI v8.0.45（10 月 27 日 23:27 发布）18、sub2api v0.2.18（10 月 23 日 15:44）19、codex-proxy v2.1.21（10 月 28 日 04:33）20、codex2api v3.1.2（10 月 28 日 04:39）21。
codex-proxy 与 codex2api 这两个版本发布于今天凌晨，比本期窗口早，本期没有新内容。
一句话收口：今晚先看自己的鉴权链上有没有插件，有就给容器设上限并给请求体设上限；sub2api 那两张补丁要等版本，dev 上那张内存补丁还没来。
References
- 1
- 2
- 3
- 4
- 5
- 6v8.0.45 sdk/access/manager.go 第 44–70 行
github.com
- 7v8.0.45 config.example.yaml 第 30–36 行
github.com
- 8sub2api PR 8390
github.com
- 9
- 10sub2api v0.2.18 channel_service.go
github.com
- 11sub2api PR 8395
github.com
- 12
- 13
- 14sub2api PR 8394
github.com
- 15codex2api PR 839
github.com
- 16
- 17sub2api PR 8397
github.com
- 18CLIProxyAPI v8.0.45
github.com
- 19sub2api v0.2.18
github.com
- 20codex-proxy v2.1.21
github.com
- 21codex2api v3.1.2
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.