证书过期 13 天，指纹页只写 0 条；补丁把出站身份改回 codex-tui
sub2api 的指纹采集站证书已过期 13 天，采集恒为 0 且页面不提示；OpenAI 号仍绑不了指纹档位，另有两条待合补丁会把 Codex 出站身份改回 codex-tui，并给请求体与 SSE 加一组新上限。
北京 22:04 到现在这三小时，四个仓库一个新版都没发。今晚要处置的是三处已经坏掉的地方，和两张会改默认值的补丁。
指纹采集站的证书 10 月 20 日就过期了，页面只显示 0 条
sub2api 的 TLS 指纹采集站挂在
tls.sub2api.org:8090，回给来访客户端一份 ClientHello 指纹。运维拿它对照自己出站的握手像不像真客户端。北京昨晚 23:47 有人把这件事报了上来：这张证书已经过期，面板却一直显示 0 条已采集1。
我按单子里的命令自己跑了一遍：
$ echo | openssl s_client -connect tls.sub2api.org:8090 -servername tls.sub2api.org 2>/dev/null \
| openssl x509 -noout -dates -subject
notBefore=Jul 22 18:05:41 2026 GMT
notAfter=Oct 20 18:05:40 2026 GMT
subject=CN=tls.sub2api.org
$ curl -s -o /dev/null -w "%{http_code} %{errormsg}\n" https://tls.sub2api.org:8090/
000 SSL certificate problem: certificate has expired到今晚，这张证书已经过期 13 天。
同一台机器的 443 是另一张证书，有效期到 12 月 18 日。这解释了为什么从浏览器打开面板、点任何按钮都一切正常。
坏掉的只有 8090。真去连它的客户端会在握手阶段失败——Codex CLI、Claude Code、Go、Python 这些按规则校验证书的实现，一个都进不来。采集器因此永远是 0 条，页面也不会告诉你为什么。
把校验跳过去就通：
$ curl -sk https://tls.sub2api.org:8090/ | head -c 400
{"alpn_protocols":[...],"cipher_suites":[...],"curves":[...],"extensions":[...],
"http2":{...},"ja3_hash":"...","ja3_raw":"...","ja4":"...","model":"...","id":"..."}字段是齐的：
ja3_raw、ja3_hash、ja4、http2、cipher_suites、curves、extensions、alpn_protocols 都在。今晚要拿它救急，就先用
curl -k 抓一份下来存着，别管校验。真正要修的是两件事：给 8090 续上证书；把到期告警盯到 8090 这张上。只盯 443，监控会一直绿。
OpenAI OAuth 号绑不了指纹档位，面板和后端两道闸都关着
同一分钟里，同一个报障人还开了第二张单：OpenAI OAuth 号在面板里找不到 TLS 指纹档位2。
面板这一侧写得很直白。
EditAccountModal.vue 第 2874 行的注释是「配额控制（Anthropic OAuth/SetupToken：亲和 + 窗口费用 + 会话 + RPM 等）」，第 2876 行的 v-if 把整块内容限定在 platform === 'anthropic' 且类型为 oauth 或 setup-token 的账号上3。
frontend/src/components/account/EditAccountModal.vue 第 2853–2902 行（sub2api v0.2.19）。第 2876 行的 v-if 开出的这一块一直延伸到下方，配额控制、会话上限和 TLS 指纹开关都装在里面，OpenAI 号整块不渲染3。后端还有一道更早的闸。
account.go 第 2483 行的 IsTLSFingerprintEnabled() 第一句就判 IsAnthropicOAuthOrSetupToken()，不符合的账号直接返回 false4。ResolveTLSProfile 见到 false 就返回 nil。所以就算绕过面板，用管理接口把 enable_tls_fingerprint 和 tls_fingerprint_profile_id 写进 OpenAI 号的凭据，出站也拿不到 profile5。OpenAI 真实转发那条路本来也不带它。
doOpenAIUpstream 走的是 httpUpstream.Do，签名里没有 profile 参数；带 profile 的是 useTLSFallback 那一支，只服务账号测试与计费探测6。那两份补丁里最要紧的一条参数是 ALPN：真 Codex CLI 不发 ALPN。Go 的
crypto/tls 默认会报 h2，单这一个字段就足以把指纹区分开。OpenAI 号今晚能调的是头部层。凭据里的
codex_fingerprint_mode 取 off、device、session、full 四档，配 codex_fingerprint_seed，改写的是 x-codex-installation-id、session-id、thread-id 这些标识，走的是 HTTP 头，跟握手无关9。今晚想把 OpenAI 号的 ClientHello 换掉，只剩改后端这条路。面板里翻不出来，管理接口写进去也不生效。
补丁要把默认出站身份从 codex_cli_rs 改回 codex-tui
sub2api 的
#8487 今天凌晨 00:35 开出，23 个文件，+357/−161，base 是 main，合并状态 unstable10。v0.2.19 现在的做法是强制统一。
request.go 第 271 行写着 CodexDefaultOriginator = CodexCLIOriginator，也就是 codex_cli_rs；第 275 行起的 NormalizeCodexClientIdentityToCLI 会把任何 codex-tui 身份连同 UA 首段一起改成 CLI，顺手删掉尾部的 (name; version) 组11。注释里写着理由：历史上 TUI 身份触发过上游的身份风控分层，#5198 里同样的请求换成 CLI 身份就过了。
配套的注释也换了说法：原来的「身份风控分层 / 命中风险身份」，改成「容量紧张时按客户端身份分优先级降载」。
同一个身份，上一版是必须洗掉的风险指纹，这一版是默认出口。方向正好相反，两边对上游行为的假设也换了。
第二块改动在空号池。
#8487 新增 maxOpenAIPoolRecoveryRounds = 3 与 openAIPoolRecoveryBaseDelay = 2 * time.Second，等待按轮线性递增，受既有的 maxRequestScopedRetryDelay = 8 秒封顶13。
backend/internal/handler/failover_loop.go 第 37–87 行（PR #8487 头分支）。第 59 行 maxOpenAIPoolRecoveryRounds = 3、第 62 行 openAIPoolRecoveryBaseDelay = 2 * time.Second，第 65–78 行的注释写明恢复只覆盖请求级瞬时故障，凭证失效、429 限额与 4xx 都在范围之外13。边界写得很清楚：只对请求级瞬时故障和输出前的 5xx 生效；凭证失效、429 限额、4xx 一律不进这个预算。上游给了
retry-after 就优先用它的值。第一次失败时还会先用 bypass 重选一次，忽略「账号 + 模型」这条瞬时冷却，免得整池候选被同一条调度偏好挡光。
v0.2.19 现在没有这一层，空池直接回
ErrNoAvailableAccounts，客户端拿到 503，只能自己重来14。同一张补丁还有一处会改行为：容量让渡现在也给「账号 + 模型」记一次瞬时降权，并把 OAuth 号纳了进来。此前只有 API-key 号的失败会进这条。
今晚能动的只有一个开关。怀疑自己的号被身份分层降载，把
gateway.disable_codex_identity_enforcement 设成 true，网关不再统一改写身份，退回「按最终 UA 配对 originator」。这个值在服务构造时发布成进程级快照，改完要重启进程。98 个文件的资源上限补丁：请求体预算 1 GiB，SSE 单行收到 40 MiB
#8484 今天 23:17 开出，98 个文件，+4045/−261，合并状态 clean，base 也是 main15。它给网关入口加了一组上限，默认值如下：
| 配置键 | v0.2.19 现值 | 补丁默认值 |
|---|---|---|
gateway.request_body_memory_budget_bytes | 无此键 | 1 GiB16 |
gateway.request_body_read_timeout_seconds | 无此键 | 120 秒16 |
gateway.downstream_write_timeout_seconds | 无此键 | 120 秒16 |
gateway.max_line_size | 500 MiB | 40 MiB16 |
gateway.sse_queue_max_bytes | 无此键 | 8 MiB16 |
gateway.sse_event_max_bytes | 无此键 | 0，沿用单行上限16 |
gateway.sse_event_max_lines | 无此键 | 409616 |
backend/internal/config/config.go 第 2525–2574 行（PR #8484 头分支）。第 2541–2543 行是 1 GiB 请求体预算与两个 120 秒，第 2564 行把 max_line_size 从 500 MiB 改成 40 MiB，第 2565–2567 行是队列 8 MiB、单事件 0、单事件 4096 行16。行为都写在补丁自带的文档里。预算耗尽回 503 加
Retry-After，单个请求超体积仍然回 413。压缩后的请求体另封顶 64 MiB，超了直接拒，不做截断。两个 120 秒各管一段：读请求体卡住 120 秒算超时；下游每一次写或 flush 单独计时。操作成功就清掉期限，上游慢慢思考不吃整条响应的时间预算。写 0 等于关掉对应那条。
SSE 那组是这批数字里唯一会立刻咬人的。
max_line_size 从 500 MiB 降到 40 MiB；sse_event_max_bytes 取 0 时直接沿用这个单行上限；sse_event_max_lines 用 4096 兜没有空行的短行流。队列那 8 MiB 有个细节：一行超过 8 MiB 就能单独占满队列，上限受单行与单事件封顶。补丁文档点名了传内联大图的站点，建议先量再调。
今晚可以先量一下自己最长的那行 SSE 有多大。一张 base64 图堆在一条
data: 里，40 MiB 并不难超。行情：四个仓库都没有新版本，上游三处全绿
| 仓库 | 最新版本 | 发版时刻（北京） | 本窗口 |
|---|---|---|---|
| CLIProxyAPI | v8.0.51 | 11 月 2 日 01:12 | 无新版17 |
| sub2api | v0.2.19 | 10 月 28 日 18:16 | 无新版18 |
| codex-proxy | v2.1.22-beta.7ae8044（预发布） | 11 月 2 日 20:24 | 窗口之前，无新版19 |
| codex2api | v3.1.2 | 10 月 28 日 04:40 | 无新版20 |
上游三处状态页今晚都干净。OpenAI 全绿，组件列表里没有非 operational 的项21；Anthropic 全绿，页面最后更新在 21:2922；Google Cloud 最新一条还是 10 月 28 日的 europe-west2 多产品故障23。
Codex 额度侧，今天 UTC 没有全局重置，最近一次已验证的重置在 5 天前，也就是 10 月 28 日 14:35（北京）。追踪站累计 61 次全局重置、10 次已存重置，节奏约每两天一次24。
另一家站的累计口径是自 2025 年 9 月 71 次，中位间隔 2.9 天，最长一次等了 68 天，最后更新在 11 月 1 日25。
CLIProxyAPI 四张单一起关了，v8.0.51 一份都不带
今晨 00:05:00 到 00:05:03，CLIProxyAPI 的 #7159、#7161、#7162、#7163 四张单在三秒内全部关成 completed，关单人是 LTbinglingfeng，四张都是 0 评论26272829。
四张单各自被一笔提交引用，最晚的一笔引用出现在北京 11 月 2 日 18:22。
主干在这个窗口只落了两笔，都在 16:00 与 16:03（UTC），改的是 README 里的赞助文案。四张单的修复进了主干，没进 v8.0.51。
#7159 值得单独说，因为它的影响面跨插件26。
插件的模型流桥用一张注册表按
StreamID 索引，StreamID 由 next.Add(1) 自增，可猜。v8.0.51 的回调层第 66 行是 h.modelStreams.read(ctx, req.StreamID)，第 87 行是 h.modelStreams.close(req.StreamID)，两处都不看调用方是谁30。
internal/pluginhost/host_model_stream_callbacks.go 第 11、44–90 行（CLIProxyAPI v8.0.51）。第 66 行按 req.StreamID 取分片、第 87 行按同一个 ID 关流，两个函数体里都没有校验调用方身份的语句30。差别就是后果：一个插件能读到另一个插件的上游分片，也能把别人的流关掉。
主干上的修法是给两个回调补上身份：从 context 取
hostCallbackPluginIDFromContext(ctx) 与 instance，对不上就报 host callback ID does not belong to the calling plugin instance。这个仓库没有对应的安全公告页，两条 GHSA 都属 8.0.45 那批老事。
升级判断因此分两种：不装插件的站，v8.0.51 可以照常升；装插件的站等下一版，几个插件同时跑在一个进程里的实例尤其要等。
今晚动手清单
- 证书：给
tls.sub2api.org:8090续期，把到期告警盯到 8090 这一张。今晚先用curl -k存一份基线指纹。 - OpenAI 号的指纹：面板没有入口，后端也判平台。今晚要动就动头部层，
codex_fingerprint_mode与codex_fingerprint_seed。 - 怀疑被身份降载：
gateway.disable_codex_identity_enforcement: true，重启进程后网关退回按最终 UA 配对。 - 传内联大图的站：量一下最长的那行 SSE。
#8484合了之后上限是 40 MiB，队列另有 8 MiB。 - 装了插件的 CLIProxyAPI：#7159 的隔离修复在主干、不在 v8.0.51，等下一版再升。
References
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8sub2api #6380
github.com
- 9
- 10修复：回退 Codex 指纹改写，号池耗尽后按 Retry-After 有界恢复
github.com
- 11sub2api v0.2.19 · request.go 第 262–298 行
github.com
- 12sub2api v0.2.19 · config.go 第 2441 行
github.com
- 13
- 14
- 15
- 16PR #8484 头分支 · config.go 第 2538–2567 行
github.com
- 17CLIProxyAPI v8.0.51
github.com
- 18Sub2API 0.2.19
github.com
- 19codex-proxy v2.1.22-beta.7ae8044
github.com
- 20codex2api v3.1.2
github.com
- 21OpenAI Status
status.openai.com
- 22Anthropic Status
status.anthropic.com
- 23Google Cloud Status
status.cloud.google.com
- 24Codex Reset Tracker
codex-reset.com
- 25OpenTheRank · Codex Reset
opentherank.com
- 26CLIProxyAPI #7159
github.com
- 27CLIProxyAPI #7161
github.com
- 28CLIProxyAPI #7162
github.com
- 29CLIProxyAPI #7163
github.com
- 30
- 31
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.