多副本下加号必挂：OAuth 会话只活在一个进程里，五个平台只有一条能跨实例
多副本部署下用面板加 OAuth 号必挂：sub2api 的登录会话存在进程内存里，两条请求分到两个节点就回 session not found or expired；本期给出五分钟判据、五个平台各自的表现、以及今晚三条不改代码的绕行办法。
这一小时四个仓库都没有发版。CLIProxyAPI 停在 v8.0.48，sub2api 停在 v0.2.19，codex-proxy 与 codex2api 分别是 v2.1.21 与 v3.1.2，两条主干也没有新提交。12
没有版本可报的这一小时，唯一值钱的新事实是一条四个月没人回的单被补上了复现。
评论写得很具体：两个后端节点，生成授权链接的请求落到节点 A，登录完提交换码的请求落到节点 B，立刻回
session not found or expired；把两次请求固定到同一节点就能继续。他还顺手排除了两个常见猜测：不是 OpenAI 登录失败，也不是美国节点与新加坡节点之间的时区差。
三条结论先放前面。
这既不是上游拒绝，也不是凭证问题，是本地内存里的一张表被两次独立的 HTTP 请求跨进程读写。换号、删号、重试都绕不开它，能绕开的只有把这两次请求钉到同一个进程。五个平台里，只有一个已经能跨实例。
一、五分钟确认是不是这一条
先看返回速度。报障人自己量的：失败请求 8 毫秒就返回，因为本地内存查表落空，一个外网请求都没发出去。3
这条判据比错误文案还硬。上游拒绝要几百毫秒到几秒，本地查表失败是毫秒级。
再看文案。同一个故障，五个平台写出来五种样子，日志里不像同一件事。
| 平台 | 换码路由 | 失败时客户端看到什么 |
|---|---|---|
| OpenAI | /openai/exchange-code | 400，OPENAI_OAUTH_SESSION_NOT_FOUND，session not found or expired |
| Claude | /accounts/exchange-code（另有 setup token 一对） | session not found or expired，走通用错误映射，落 500 |
| Gemini | /gemini/oauth/exchange-code | 400，Failed to exchange code: session not found or expired |
| Antigravity | /antigravity/oauth/exchange-code | 400，Token 交换失败: session 不存在或已过期 |
| Grok | /grok/oauth/exchange-code | 400，GROK_OAUTH_SESSION_NOT_FOUND；用过一次再换回 ALREADY_USED |
OpenAI 那条带错误码，在面板与日志里最好搜。5
Gemini 的是 400 加一句拼进去的文案。6
Antigravity 用中文写，
session 不存在或已过期，前面还挂着「Token 交换失败: 」。7同一个病因，面板上一个报 400、一个报 500。别拿状态码当分类依据。
最后算概率。N 个副本、负载均衡按连接轮转，两条请求落进同一个进程的机会大约是 1/N。报障人实测 7 次里只成了 1 次，和他的部署规模对得上。
二、代码为什么必然这样
会话对象本身没什么特别，五段字段加一个创建时间。关键在于它被存在哪儿。
backend/internal/pkg/openai/oauth.go 第 30–56 行（v0.2.19）：第 34 行 SessionTTL = 30 * time.Minute，第 53–55 行就是这个结构体，注释原话是 manages OAuth sessions in memory。1030 分钟是给「打开授权页、登录、回贴 code」留的余量，和跨进程没有关系。
第二处：生成链接和换码是两次独立的 POST，前端点两次，负载均衡分两次。
backend/internal/server/routes/admin.go 第 455–462 行（v0.2.19）：第 459 行 generate-auth-url、第 460 行 exchange-code，两行各自一个 handler。Gemini、Antigravity、Grok 的换码路由在同文件的第 477、486、496 行，形态一样。11服务对象是单例，在依赖注入时构造一次，活到进程退出。所以这张表属于「这个进程」，不属于「这次登录」。
于是就有了这一幕：A 进程收下 session，B 进程拿着同一个 session_id 查自己那张空表。
三、五个平台里只有 Grok 能跨实例
仓库里其实已经有跨实例的实现，只是没给这四条用。
redissession 这个包的注释第一句就是「multi-instance OAuth session backend」，除读写之外还提供单次消费标记。12Grok 的会话存储为此留了一个替换口子，注释写明是为了 cross-instance single-use callbacks。13
注入点在 wire 里，条件是 Redis 客户端非空。
backend/internal/service/wire.go 第 19–28 行（v0.2.19）：第 24 行 if redisClient != nil，第 25 行把 Grok 的存储换成 Redis 版本；OpenAI、Claude、Gemini、Antigravity 四个服务没有对应分支。14
backend/internal/pkg/xai/oauth.go 第 113–121 行（v0.2.19）：第 118 行 redissession.New(rdb, "oauth:session:xai", SessionTTL)，key 前缀与 TTL 都在这里定死。要照抄给别的平台，改前缀即可。15有一处细节值得记住：Grok 的进程内 map 并没有删掉，Redis 只是加在上面的一层。写入远端失败时，它把 session 记进本地并打一条 warn，退回单机语义。15
也就是说，「配了 Redis」不等于「一定共享」，还要看那条 warn 有没有在刷。
顺带纠正一种常见说法：不是「五个平台全都在内存」。准确说是四条纯进程内、一条有远端层。
四、今晚加号能走的三条路
按代价从低到高，三条都能立刻用，互不冲突。
一，把这两条路由在负载均衡上做成路径粘滞。 只钉
/api/v1/admin/openai/* 与另外四个平台的换码前缀，别整个面板都粘。粘整个面板的代价是管理操作全挤到一台机器上。二，加号时直接开某台节点的地址，绕开负载均衡。 浏览器的两次请求都打同一个进程，问题当场消失。这条路不需要改任何配置，适合临时补几个号。
三，临时把副本数收到 1，加完再放开。 最笨也最稳。代价是这段时间里没有冗余。
三条之后都要验一遍：面板上连加两个号，看日志里还出不出现那句文案。
journalctl -u sub2api --since '10 min ago' \
| grep -E "session not found or expired|session 不存在或已过期"没有任何输出，说明两次请求落在同一个进程里了。还有输出，说明粘滞规则没命中那条路径。
五、今晚别做的三件事
别调 TTL。 30 分钟改成 60 分钟，跨进程仍然读不到。这个数只影响「同一进程里会话能活多久」。
别反复重试换码。 session 在 A 的内存里，B 永远不会命中。重试整轮（重新生成链接再登录）才有一点概率，因为那等于重掷一次 1/N。
别删号、别清浏览器缓存。 两者都和这张表无关。删号能「好」，是因为你重新走了整轮流程，而不是因为删号修好了什么。
另外提醒一句：Grok 那条如果是
ALREADY_USED，那不是同一个病。它是有意的单次消费，第二次换码必然被拒。16六、别和上一期那条「会话粘性」混起来
上一期写过 CLIProxyAPI 的
session-affinity 只在进程内。那是另一件事。那个「会话」指的是同一个对话要钉到同一个账号，为的是 prompt 缓存和思考签名。
这里的「会话」是登录过程中那张临时表，钉的是同一个进程。
两个都叫粘性，作用对象完全不同。前者配错了表现为缓存命中率掉、上下文被重置；后者配错了表现为加号直接报错。
七、版本与上游
四仓窗口内零发版、零主干提交；codex-proxy 与 codex2api 连新条目都没有。
OpenAI 那条图片编辑事件还是老样子：16:06 转 monitoring 之后没有新 update，
resolved_at 仍是空。17组件级仍是 Images 的
degraded_performance，整站 minor。18图片编辑这条链路继续别对着一个号扇出重试。
Claude 状态页全绿，今天没有事故。19
额度重置没有发生。追踪站上今天 UTC 没有新帖，最近一次已验证的全局重置仍是 10-28 06:35（UTC），累计 61 次、10 次 banked。20
本窗口其余条目
| 条目 | 买什么 | 状态 |
|---|---|---|
| #7127 | 给 CLIProxyAPI 加 Kiro 的 AWS SSO 与 Builder ID 登录 | open，零正文，北京 00:59 开 |
| #7079 | AI Studio 通道 400 PROXY_GENERATION_DISABLED | 已关闭（completed），窗口内新评论只是追问，没有新解法 |
sub2api 这一小时有五条前端样式（#8452 / #8451 / #8450 / #8449 / #8447）与一条 Creem 支付接入（#8423），都属界面与收款，与额度风控无关，本期不收。#2420 只有一条 CLA 机器人留言，#764 是交流群顶帖，按噪声处理。
今晚的动作
先看那 8 毫秒。 加号失败如果毫秒级返回，按本文这一条处理；几百毫秒以上才该去看上游。
确认自己是不是多副本。 单副本部署不会碰到这个问题，别在这上面浪费时间。
按第三节三条路里的任意一条，把加号做完。 粘滞、直连节点、临时单副本，选哪条取决于你的负载均衡能不能改。
顺手查一眼 Grok 的 warn。 日志里搜
xai oauth session Redis write failed。有这条就说明 Redis 没通，那条链路也在按单机跑。15别等版本。 这张单开了四个多月，今天才有第一条评论，维护者没有任何表态。修不修、什么时候修，都不该进入你今晚的排期。
References
- 1CLIProxyAPI v8.0.48 发布页
github.com
- 2sub2api v0.2.19 发布页
github.com
- 3sub2api #3307
github.com
- 4第一条评论
github.com
- 5openai_oauth_service.go (v0.2.19)
github.com
- 6gemini_oauth_service.go (v0.2.19)
github.com
- 7antigravity_oauth_service.go (v0.2.19)
github.com
- 8oauth_service.go (v0.2.19)
github.com
- 9errors.go (v0.2.19)
github.com
- 10openai/oauth.go (v0.2.19)
github.com
- 11routes/admin.go (v0.2.19)
github.com
- 12redissession/store.go (v0.2.19)
github.com
- 13grok_oauth_service.go (v0.2.19)
github.com
- 14service/wire.go (v0.2.19)
github.com
- 15xai/oauth.go (v0.2.19)
github.com
- 16grok_oauth_service.go (v0.2.19)
github.com
- 17事件详情
status.openai.com
- 18OpenAI status summary
status.openai.com
- 19Anthropic status
status.anthropic.com
- 20codex-reset feed
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.