每条长连接钉住 32 MiB，而那份错误日志根本不会写出来：CLIProxyAPI 的两张新 PR

一、默认配置下，一条长连接钉住最多 32 MiB

• 每轮的上游请求体都留在同一条连接上，直到 socket 关闭，总量上限是整份 32 MiB；
• 预算花光之后，每轮仍会追加一个只有头、体为空的条目，条目数随轮数涨；
• 被留下来的体属于最早的几轮，最后失败那轮的那份往往早就被裁成零。

更麻烦的一层：这份日志压根不会写出来

今晚能动什么

1. 把单实例的长连接并发压住——每条最多 32 MiB，乘上并发数就是最坏情况；
2. 在反代侧给长连接设存活上限，让客户端按小时重连，把滞留的时间窗切短；
3. 把进程 RSS 与连接数画在同一张图上，一旦内存随连接数阶梯上升，就按这条算账。

二、同一作者的第二条，只是开销

三、版本、上游、额度与社区

• 北京 02:52，Antigravity 分区有人报付费的 Google AI Pro 学生档被后端当成试用档：设置页显示已付费，模型选择器里 Sonnet 5.5 与 Opus 5.5 消失、Gemini 4 Argon 灰着，重发 OAuth 令牌、清缓存都没用，只能等后台重同步。27
• 北京 03:30，同一分区一条 Linux 上的 OAuth 深链故障：回调被交给 VS Code，随后会话被判未认证。28
• 北京 02:53，Gemini API 分区一条 Vertex 账单：某项目平时月均 6 美元，两天内涨到 4.5 万美元。29

今晚的处置顺序

1. 先量：把 RSS 与 WebSocket 连接数画在同一张图上。内存随连接数阶梯上升，就是 #6960 这条路；平坦就把注意力放回别的。
2. 再限：反代侧给长连接设存活上限、给并发设闸。这一步不依赖版本，今晚就能做。
3. request-log 保持默认关：它是排查时临时打开、抓完就关回去的开关；打开后日志写进文件，代价从内存搬到磁盘与 IO。
4. 盯两个信号：bc064340 之后的第一笔提交；#6960 的合并状态——合并之后 logging.MarkDeferredAPIRequests 会出现在 dev 整包里，那时才谈得上等版本。
5. 性能那条不用等：它只决定同样的流量下 CPU 与 GC 的压力。