10/20 夜间速报：cyber 会话屏蔽一开，同出口超 256 条历史的会话全被判成已封锁
四仓这一小时没有新版本，但 sub2api 的 cyber 会话屏蔽在开关打开后，会把一次真实策略命中扩散到同一出口的其它会话：历史超过 256 条就直接本地回 403；本期给出发行版里的三处代码位置、怎么一眼认出是本地拦的，以及一张搁了六周没合的补丁。
北京 20:38 到 21:20 这四十分钟，四个中转仓库没有新版本，主干也都没动。
21:13，一条 9 月 8 日就开着的报障单下面多了一份线上证据：开了 cyber 会话屏蔽之后，一小时里同一出口留下 90 条本地 403，其中 80 条是被历史长度判掉的1。
这一小时该动的东西就在这里。
结论：403 是本地判的，账号没被碰
客户端看到的是
session_blocked_by_cyber_policy，HTTP 403，提示「该会话已被网络安全策略屏蔽，请开启新会话」2。这条拒绝发生在选账号之前。Ops 记录里连账号 ID 都不写，代码注释直说「请求在账号选择前即被拒绝」3。
所以别去号池里找坏号，那里不会有答案。
影响面不止命中的那一个会话。同 Key、同出口 IP、同归一化 User-Agent 的其它会话，只要历史超过 256 个条目，一起被拒。
机制：一次命中点亮一片来源
封锁键由三个东西合成：API Key、客户端 IP、归一化后的 User-Agent，算出来叫来源范围4。
上游真判了一次
cyber_policy，本地就把那条会话的指纹写进封锁表，并把整个来源范围置为 active。之后每个请求先按显式会话 ID 查一次。这一查没命中，就落到范围分支。
范围 active、历史又超过 256 个条目，函数直接返回
transcript_lookup_limit_exceeded，不做精确匹配5。256 是消息与工具条目数，既不是 token，也不是对话轮数。需要上百步的编码会话，很容易过线。
带显式会话 ID 也不保你。它只是先查一次，查不到照样往下走。
发行版里能核到的两处
backend/internal/service/openai_cyber_session_block.go 第 117–154 行。第 128–136 行先查显式会话，第 138–145 行取范围键并读 active，第 148 行一旦 lookupKeysTruncated 为真就返回封锁键5。第 149–150 行的注释把理由写得很直白：范围一旦激活，静默丢掉旧候选，被封锁的客户端就能靠追加无意义条目逃掉匹配。
这条行为在仓库自己的测试里被断言过。
TestFindCyberSessionBlockedForRequestFailsClosedOnScopedTranscriptOverflow 只把范围设成 active、没有任何封锁键，也断言请求应当被拒6。
backend/internal/service/openai_cyber_transcript.go 第 13–29 行。第 21 行是常量 256，上面两行注释写的是「限制单次请求的 Redis 查询量，保留最近的前缀」7。报障人核过 v0.2.3 与 9 月的 main，本刊又核了这一版发行版：分支还在，常量还是 256，注释也没改。
怎么认出这次 403 是本地拦的
看 Ops 记录四个字段就够：
error_type 是 cyber_policy_session_blocked，error_source 是 gateway_local，状态码 403，严重级 P33。error_body 里带 session_block_key=。值等于 transcript_lookup_limit_exceeded 就是超限这条路径，是别的哈希才是真的指纹命中。两个判据要分开用。
error_source 是 gateway_local 说明本地拒的；日志里如果是上游 cyber_policy，那是上游真判了，处置完全不同。还有一条容易忽略：这条记录不进内容审计、不计违规次数，因为请求从没到过上游3。
今天能做的三件事
先看开关。后台设置项
cyber_session_block_enabled 默认关，值必须是字符串 true 才生效；cyber_session_block_ttl_seconds 缺省 3600 秒8。没开过这一项的站，不受这条影响。开着又不想承担误拦，先关掉它。要保留拦截能力，就打下面那条补丁。
升级不会立刻干净。旧记录在旧命名空间里、不迁移，按原有 TTL 自然过期；滚动升级要覆盖到全部实例才消除旧逻辑；下游网关已经记下的限制也不会自动解除。三句都出自补丁说明9。
补丁：按显式会话隔离，还开着
PR #6834 就是开单的人自己提的。9 月 8 日 18:00 提交，最后一次更新是 9 月 18 日 19:12，10 个文件 +167/−391，base 是
main，至今没合9。改法三步：封锁键只由显式会话头派生（
session-id、session_id、conversation_id 等），IP 与 UA 不再参与；整段超限拒绝分支删掉；换到 v2 命名空间，避免把旧的缓存键记录当成显式会话封锁。
aofee/sub2api@codex/cyber-session-isolation 的 openai_cyber_session_block.go 第 91–113 行。第 95 行签名末尾两个参数已是 _ string, _ string，第 91–94 行注释写明「来源元数据与历史长度不能证明请求属于曾被封锁的会话」10。代价要说清：没有显式会话 ID 的下游请求，从此不再有跨请求的会话级拦截，只有上游真实拒绝继续透传。
共享一个 Key 的转发网关，得自己给每个下游会话一个稳定且不重复的 ID，否则在新逻辑下等于没有会话级拦截。
还有一句：报障人的现场是自建镜像，revision 与官方发行版不同。本刊核的是 v0.2.17 这一版的代码，两边结论一致。
次级：伦敦区出了第 6 版
20:44，谷歌云那条事故更新到第 6 版：截至 05:10 PDT（北京 20:10），europe-west2 的大部分工作负载已在恢复；下一次更新承诺 07:00 PDT（北京 22:00），结束时间仍空11。
症状没变，仍是 europe-west2-b 不可用、区域内部分服务报错。受影响产品仍是 38 个，清单里没有 Vertex AI，也没有 Gemini API。
所以今晚不用为这条事故动 Gemini 号池。跑在该 region 的自建上游节点另算。
这一小时的其余状态
| 仓库 | 当前发行版 | 主干最新提交 | 窗口内 |
|---|---|---|---|
| CLIProxyAPI | v8.0.35，10-20 03:08 发布12 | main 12:23、dev 18:54 | 无条目变化 |
| sub2api | v0.2.17，10-16 12:41 发布13 | main 10-19 20:45 | 三张新补丁、一条跟帖、一条旧单补证 |
| codex-proxy | v2.1.19，10-20 05:10 发布14 | dev 10-20 04:57 | 无 |
| codex2api | v3.1.1，10-17 05:46 发布15 | main 10-17 05:35 | 无 |
sub2api 那三张是同一位作者在 20:39–20:40 连开的 antigravity 补丁：
#8244 保留小数配额、#8245 本地用量统计、#8246 并行工具结果顺序。三张都还开着，与本期的处置无关，只登记不展开。#8239 那条 503 长帖窗口内只多一条「直接用 codex 也报错」的跟帖，没有新的档位或网段信息，本刊不重复前几期的叙述。上一期的主线
#6800 与配套的 #6801，窗口内无新评论、无新提交，两条都还开着。上游与额度
- OpenAI 状态页全绿，0 个活动事件、0 个降级组件；最近一条事件仍是 10-19 21:31 的下载报错，22:14 恢复16。
- Anthropic 全绿，今天没有事件17。
- Codex 重置：最近一次已验证的全局重置是今天 14:33，七小时前，窗口内没有新的；站点记 56 次全局、10 次 banked18。
- 另一家追踪站记 64 次重置、中位间隔 3.1 天、最长 68 天，页面更新到今天19。
- 官方社区 Codex 分区窗口内 0 条新话题，最新仍是 19:32 那条 Windows 依赖目录备份问法，与中转运维无关，本刊不收20。
这一小时没有该升的版本。
今晚要动的是开关：把
cyber_session_block_enabled 那一栏先看一眼，比在号池里翻坏号有用得多。References
- 1sub2api issue 6831 下面的线上证据
github.com
- 2sub2api issue 6831
github.com
- 3
- 4
- 5
- 6v0.2.17 的同名测试
github.com
- 7同一份文件
github.com
- 8v0.2.17 domain_constants.go 第 238–240 行
github.com
- 9sub2api PR 6834
github.com
- 10补丁分支上的实现
github.com
- 11Google Cloud 事故 Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 12CLIProxyAPI releases
github.com
- 13sub2api releases
github.com
- 14codex-proxy releases
github.com
- 15codex2api releases
github.com
- 16OpenAI Status
status.openai.com
- 17Anthropic Status
status.anthropic.com
- 18codex-reset.com
codex-reset.com
- 19OpenTheRank Codex Reset Tracker
opentherank.com
- 20Codex on Windows: how are you backing up dependency trees
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.