10/17 深夜速报：易支付回调要再查一次上游单，插件模型在 8.0.29+ 静默消失 (2026)

10 月 17 日北京 21:25 到 22:20 这不到一小时里，四个仓库都没有发新版本：sub2api v0.2.17、CLIProxyAPI v8.0.32、codex-proxy v2.1.18、codex2api v3.1.1 仍是各自的最新版。1 2 3 4

CLIProxyAPI 的 dev 分支在这小时里进了两笔提交、开出一条新 issue，主干与另外三个仓库停在原位。5

这一小时里，唯一已经落在发行版里的动作，在 sub2api 的收款回调上。

易支付回调现在要多查一次上游订单

v0.2.17 是 10 月 16 日中午 12:41（北京）发布的。发行说明里，这一条只有一句话：修复易支付查单参数无法被识别、数字字符串解析失败，回调确认后再入账。6

易支付是一类第三方聚合支付网关，彩虹易支付与 ZPay 是最常见的两个实现。落到代码上，是 EasyPay.ConfirmNotification 这一段。7

验签通过之后，它再拿 out_trade_no 去上游 api.php?act=order 查一次。

三个条件全过才入账：上游报已付、金额落在容差内、trade_no 对得上。7

v0.2.16 的同一个文件里搜不到这段，它是 v0.2.17 新加的一道。8

任何一条不过，webhook 就回 502 给支付网关，订单停在待确认。9

同一处还会在审计里留一条 PAYMENT_UPSTREAM_UNCONFIRMED，带查单失败的原因。10

报障单号是 #8171，标题写着「更新 v0.2.17 后充值无法回调」。北京 20:55，维护者 StarryKira 在这条报障下回了方向：更新了安全机制、上一个版本有漏洞，易支付回调验签通过后要再调一次上游 api.php?act=order。11

将近一小时之后，开单人还在问「在哪里可以设置」。同一串评论里，另一位报障人说改了后端易支付源码之后恢复了。11

哪些网关会卡住

你的易支付实现	升级 v0.2.17 之后
官方彩虹易支付、ZPay	查单参数同时放进查询串与表单，读得到
自建或魔改，只认表单参数	上游回 `No Act!`，回调 502，订单停在待确认
不实现 `act=order`	查单失败，同上
能返回 `trade_status=success` 与 `money`	金额与单号对上，正常入账

第二行的依据是 v0.2.17 里的注释：彩虹易支付与 ZPay 只从 $_GET 读参数，正文里的参数会被忽略，所以这一版在两处都发。7

今晚能做的三件事

先在后台把卡住的订单手动确认，别让用户等网关重试。
拿一笔测试单手工请求一次 api.php?act=order&pid=…&key=…&out_trade_no=…，看回包里有没有 trade_status 或 status:1 与 money。
网关确实不支持查单，只有改网关，或者退回 v0.2.16。退回的代价是把这道验签后的确认一起退掉。

sub2api v0.2.17 的易支付回调确认 — sub2api v0.2.17 的 `easypay.go` 第 409–436 行：验签之后先跑 `queryOrder`，第 421 行判上游是否已付、第 425 行判金额、第 429 行判 `trade_no`，任一条失败即返回错误。原文见该文件。

旧的文件快照会盖掉新前缀，修复只在 dev

北京 21:40，CLIProxyAPI 的 dev 分支进了一笔提交 c4c1d43e，标题是 feat(auth): prevent stale file snapshots from overwriting later persisted state。12

这笔提交的说明末尾写着 Closes: #6709，改动 8 个文件、+518/−2，其中两份是新增测试。12

13 分钟之后的 16b53545 只给一个测试加了等待助手，Closes: #6712，它只补测试，行为不变。13

问题本身由 #6709 的报障人 TonyYanS 描述：管理端 PATCH 把新前缀写进磁盘、运行时到 generation 26 之后，一个未版本化的文件快照把运行时换回旧值，generation 涨到 27。14

结果是磁盘上留着新值、运行时里是旧值，新前缀下的模型调用不通。14

v8.0.32 拦不住这一下，原因在它的过期判定里。15

isStaleCoreAuth 只比 RegistrationEpoch 与 Generation 两个数，注释写着「Generation 0 is left unversioned (file-watcher synthesizer snapshots)」。15

第 561 行的条件要求 Generation 大于 0，文件监听器合成的快照恰好是 0，于是永远不算旧。15

判定之后，第 449 行直接 Update，没有再看磁盘。16

修复分三步：快照绑定源文件路径与内容摘要、提交前重读磁盘比对、提交时清掉绑定。12

管理器一侧多了一道 updateModeReplace 加 HasFileSnapshot 的守卫，磁盘内容对不上就整笔跳过。17

命中之后会看到什么

报障人的现象很具体：那个前缀下的模型从列表里消失、调用不通，直到下一次成功的持久化把运行时改回来。14

v8.0.32 的 auth/types.go 里搜不到 HasFileSnapshot，发行版不含这笔修复，主干也还停在 10 月 16 日。12

用前缀区分账号或模型的实例，管理端的账号 PATCH 与磁盘上的自动回写尽量错开；真撞上了，把那个账号的前缀重新保存一次，就能回到磁盘上的值。

v8.0.32 的过期判定 — v8.0.32 的 `sdk/cliproxy/service_auth.go` 第 549–570 行：第 559–560 行的注释写明 Generation 0 被留作未版本化，第 561 行的条件因此放过了所有文件监听器合成的快照。原文见该文件。

dev 分支新增的新鲜度守卫 — dev 分支的 `sdk/cliproxy/auth/conductor_lifecycle.go` 第 244–262 行：在 `updateModeReplace` 且带文件快照时，第 254 行重读磁盘比对，对不上就返回当前状态、不写运行时。原文见该文件。

插件注册的模型，从 8.0.29 起会被静默丢掉

CLIProxyAPI 的 #6718 在北京 21:57 开出，讲的是另一个方向的丢失：插件提供的模型从 /v1/models 里消失，日志里什么都没有。18

报障人说，从 v8.0.23 升到 v8.0.29 之后，trae 与 workbuddy 两个插件（来自第三方仓库 mmqz/cpa-multi-plugins）的模型就不见了，回滚到 v8.0.23 立刻回来。18

报障人把根因定位到 8.0.29 里的那笔 08e5762a，它把无条件的 RegisterClient 换成了 RegisterClientIfEpochCurrent。18

这个函数在版本间的分布，本刊逐版核过：v8.0.23 与 v8.0.28 的 model_registry.go 里 0 处，v8.0.29 与 v8.0.32 各 2 处。19

在 v8.0.32 里，函数从第 449 行开始。20

第 452 行的条件是 epoch 不等于开始时拍下的值，接着就 return false。这条返回路径上没有日志、没有重试、没有错误码。20

触发器在报障人那里写得很清楚：插件在自己取模型时回写凭证文件，文件监听器因此再注册一次。18

重入的那次先发布、把 client epoch 加一；原来那次 CAS 失败，模型被丢掉。18

本轮 dev 上唯一的动作是给另一处测试加等待助手，栅栏本身没动，这条 issue 仍是 open、0 评论。13 18

该怎么办

8.0.29 之后、又靠插件提供模型的部署，升级后用 /v1/models 逐条比一次。缺了就回 v8.0.23，或者把插件那条回写路径关掉。

模型注册栅栏的静默返回 — v8.0.32 的 `internal/registry/model_registry.go` 第 447–459 行：第 452 行把 epoch 不匹配与发布回调失败并进同一个条件，第 453 行直接返回 false，调用方拿不到任何原因。原文见该文件。

坏 JSON 那条，维护者关掉了

北京 21:45，维护者 luispater 评论并关闭了 #6711，状态是 not planned。21

理由原话：发合法 JSON 是客户端在 API 契约下的基本责任，代理不替客户端修、不改写、也不特殊处理；建议去那个客户端项目提 issue。21

上期正文记过这条：五个推理入口都不校验请求体，坏 JSON 会被改写后转给上游。现在的结论落在「不加代理侧校验」上。21

对中转站的意义在账上：这类请求照样占一次上游调用、消耗一张凭证，400 还是上游回的。

另有一条：codex2api 在改 Claude Code 到 Codex 的映射

北京 21:07 开出的 PR #796，15 个文件、3 次提交，21:44 还在更新，未合并。22

作者自述的改动里有两条值得中转站注意：映射路径解析 Claude 的会话身份并按 API Key 隔离会话缓存；图片缺 source、来源不是 base64、数据为空时明确报错。22

第二条针对的是此前的静默丢弃：客户端以为图片发出去了，Codex 那一侧根本没有收到。这段是作者的自述，本刊没有独立复现。

上游与额度：本窗口没有变化

OpenAI 状态页全绿，活动事件 0；最近一条仍是 Compliance API 的成本数据延迟，10 月 15 日凌晨起、10 月 16 日 18:44（北京）标记解决。23

Anthropic 全绿，10 月 17 日没有事件。24 Google Cloud 的 incidents.json 仍是 7 条，最近一条停在 10 月 8 日到 9 日的 Cloud Storage。25

Codex 重置今天按 UTC 还没发生：最近一次已验证的全局重置在 10 月 15 日 14:13（北京），累计 54 次全局重置、10 次 banked，节奏约 4 天一次，24 小时内 42%、48 小时内 66%。26

Codex 负责人 @thsottiaux 本窗口没有新帖，最近一条是 10 月 16 日 13:51（北京）。27

OpenAI 开发者社区的 Codex 分区窗口内没有新话题，最新一条停在 19:58（北京）。28

Reddit 两个板块在窗口内各有一条，都按排除规则没有收录。r/OpenAI 21:54 那条抱怨 500 美元档与 200 美元档的限速（原帖），r/ClaudeAI 21:46 那条问 Claude for Science（原帖）。两条都是个人体感与提问，没有可核的用量数据。

挂着没动的

近两期登记的 CLIProxyAPI #6716、#6717 与 sub2api #8177、#8180、#8179 都还是 open，本窗口没有新评审。29 30

本期新增三条待跟：#6709 已修在 dev、未发版；#6718 还没有修复；#8171 的维护者给了方向，开单人尚未确认。11 14 18

下期回看三件事：下一个 CLIProxyAPI 版本带不带 c4c1d43e；#6718 会不会补上日志或重试；#8171 的报障人最后怎么解决。

References

1
sub2api releases
github.com
2
CLIProxyAPI releases
github.com
3
codex-proxy releases
github.com
4
codex2api releases
github.com
5
CLIProxyAPI dev 提交时间线
github.com
6
v0.2.17 发行说明
github.com
7
easypay.go 第 409–436 行
github.com
8
v0.2.16 easypay.go
github.com
9
payment_webhook_handler.go 第 120–132 行
github.com
10
payment_fulfillment.go 第 60–88 行
github.com
11
issue #8171 评论
github.com
12
提交 c4c1d43e
github.com
13
提交 16b53545
github.com
14
issue #6709
github.com
15
service_auth.go 第 549–570 行
github.com
16
service_auth.go 第 425–450 行
github.com
17
conductor_lifecycle.go 第 244–262 行
github.com
18
issue #6718
github.com
19
v8.0.23 model_registry.go
github.com
20
model_registry.go 第 447–459 行
github.com
21
issue #6711 评论
github.com
22
PR #796
github.com
23
status.openai.com
status.openai.com
24
status.anthropic.com
status.anthropic.com
25
status.cloud.google.com
status.cloud.google.com
26
codex-reset.com
codex-reset.com
27
@thsottiaux
x.com
28
Codex 分区
community.openai.com
29
issue #6716
github.com
30
PR #8180
github.com

CLIProxyAPI 的 dev 分支在这小时里进了两笔提交、开出一条新 issue，主干与另外三个仓库停在原位。5

这一小时里，唯一已经落在发行版里的动作，在 sub2api 的收款回调上。