v8.0.44 默认打开响应压缩与 WebSocket 压缩；十一张单在发版前一分钟一起关掉

升级后行为就变的两处

下行响应压缩

• 客户端 Accept-Encoding 里声明了 zstd 或 gzip。同 q 值服务器优先 zstd，其次 gzip。
• 不是 WebSocket 升级请求——中间件第一句就判 Upgrade: websocket 并直通。
• 响应体的类型在可压名单里：text/*、application/json、+json 结尾、javascript、svg+xml。

Codex WebSocket 压缩

默认关的那一项

十一张单在八秒内结清

发现协议：管理端点不再广播

同一窗口新开的 #7017：这条 429 还是被当额度耗尽

HTTP 429
Retry-After: 8–515
{"error":{"type":"rate_limit_error","code":"turn_rate_limit_exceeded",
 "message":"Codex is at capacity, please try again later"}}

1. isCodexUsageLimitError 只认 error.type == usage_limit_reached。注释还专门写了 rate_limit_error 有意排除、应当重试。19
2. isCodexModelCapacityError 要求文案里同时出现 model 与 at capacity。Codex is at capacity 里没有 model，落空。20
3. 于是进通用 429 分支：Auth.Quota.Reason 写成 quota、StatusMessage 写 quota exhausted，冷却按 1 秒起翻倍、10 秒下限、30 分钟封顶。2122

一处要更正的默认值

今晚能做的

版本面

• CLIProxyAPI v8.0.44 于北京 23:49 发出，tag 与 main、dev 头是同一个提交 1f917e77。1
• sub2api 仍 v0.2.18（10-23 15:44），主干停在 10-25 21:48。27
• codex-proxy v2.1.20、codex2api v3.1.1，两仓窗口内零新版本。2829
• 同窗口另有三条未合并条目，都不影响今晚处置：#7016 Vertex 裸 Tink 思考签名、sub2api #8360 可选 Batch API、codex-proxy #878 桌面端内更新。30
• 上游全绿：OpenAI 最近一条是 10-23 的 CIMD 降级、Claude 无活动事件、GCP 最新仍是 10-22 的 europe-west2。313233
• 重置信号没动：最新帖仍是 10 月 26 日 14:05 那条，signal 未激活。34

今晚的四件事

1. 升级前先确认有没有自研客户端或前置代理不认 zstd。不认的话要么别让客户端声明它，要么升级后把 server.response-compression.enabled 设成 false。
2. 如果链路里有抓包、按字节计量或审计留痕，先看压缩后的体积变化——流式响应现在一开口就压，min-bytes 管不到它。
3. 要关 WebSocket 压缩，记得它同时管 Codex 与 xAI 两条 WebSocket。
4. 撞到 Codex is at capacity 的 429，别只看 429 本身：日志里搜 reason=quota，确认是不是被误判；然后按模型摘除或调重试参数，别全局关冷却。