10/18 午间速报：没有查单接口的支付网关，升到 v0.2.17 后每笔已付订单都进不了账
10 月 18 日北京上午两个半小时：四仓没有新版本；sub2api 那道回调查单在没有 api.php 的网关上把每一笔已付订单挡在门外，CLIProxyAPI 修插件模型消失与每分钟 429 放大的两笔提交都还只在 dev；另附两处凭证被冲掉、被注销的窗口。
这一期覆盖北京 10 月 18 日 08:49 到 11:15，两个半小时。四个仓库都没有新版本：sub2api 还是 v0.2.17、CLIProxyAPI v8.0.32、codex-proxy v2.1.18、codex2api v3.1.11234。
CLIProxyAPI 的 dev 分支在窗口里进了两笔提交，main 还停在 10 月 17 日凌晨 02:56（北京）5。
三件事按急迫程度排：先是钱，没有查单接口的支付网关升级到 v0.2.17 之后，每一笔已付订单都停在入账之前；后两件都在 dev 上刚修好——插件模型会从
/v1/models 消失，Claude 的每分钟 429 会被放大成四小时冷却。另外两张报障指出 v8.0.32 里凭证会被并发改写冲掉、会被扫描注销，两条都还开着、都还没有实测。
一、没有查单接口的网关，v0.2.17 之后每笔已付订单都进不了账
sub2api 这张 PR 在窗口末尾开出（北京 11:04），作者 crhywun，9 个文件 +185/−4，状态 open、合并状态 unstable6。
它报的是 v0.2.17 引入的那道回调确认。验签通过之后，服务端还要拿
api.php?act=order 去问一次上游，问不通就回 502、订单不入账。有些网关只做了易支付协议的提交与通知两半，没有查单端点。作者点名 BEpusdt 的兼容模式：这条路径由 gin 直接回
404 page not found。拿回一页纯文本之后，代码直接
json.Unmarshal，报 invalid character 'p' after top-level value，第 370 行给它包上 easypay parse query 的前缀。审计里留下的就是这一句：
easypay confirm: easypay parse query: invalid character 'p' after top-level value。结果是验签通过、金额也没有问题，订单照样不入账；网关那侧每次重发通知，收到的都是 502。
同一个函数，10 月 17 日深夜那期写的是「查到了单、但上游报未付」；这一类网关连查单端点都没有8。
作者给的恢复路径是回滚到 v0.2.16，他在 PR 正文里写明回滚之后入账恢复。
PR 自己加了一个按实例的配置键
confirmNotify：留空或写 enabled 保持 v0.2.17 的行为，写 disabled 就跳过上游查单，签名、pid、金额三重校验照旧；顺带让查单检查 HTTP 状态码，非 2xx 报成 upstream returned HTTP <code>。这个键还没合并，今天不能当成品用6。自检两步：先看 webhook 日志里是不是 502，再去审计里搜
easypay parse query。两条都对上，你的网关就属于这一类。
post（第 344 行），它只回传响应体；拿到 404 的纯文本页面之后直接 json.Unmarshal（第 369 行）。整段没有一处读 HTTP 状态码。7二、插件模型从 /v1/models 消失，dev 上刚修完
CLIProxyAPI 的 dev 在窗口里落了 f75ea073（北京 10:32），提交说明写着
Closes: #6718，4 个文件 +556/−60，其中 435 行是新加的回归测试9。这次补的是围栏之后的那一步。注册开始前先取一次 publication fence，计算过程中凭证或注册表 epoch 变了，这一次发布就丢掉。
丢掉之后还有下一道。完成阶段拿到
published=false 时，函数会按最新那份凭证重算一遍，把模型补回来；注释写着重算用的是最新快照，被废掉的那次结果不会重新发布11。丢弃时还会留一行 Warn：
model registration for auth %s was superseded during computation; discarded the stale publication instead of overwriting the latest auth state。这一行是旧版的空白处。v8.0.32 的完成阶段在第 582 行直接调一次注册、不接返回值，第 586 行就接着去对账状态，既没有
published，也没有重算分支12。所以发行版仍是旧行为。跑插件方案的人，
/v1/models 还得自己盯；回写凭证正是这次被围栏挡下的那类并发，靠重存一次凭证把模型刷回来，不一定管用。能自己从 dev 编的就编，不然等下一个版本。
三、每分钟 429 不再被放大成四小时冷却
同一天 dev 又落了一笔 db1bab01（北京 10:50），提交说明是
Closes: #6719，5 个文件 +390/−2，其中两个是新加的测试文件13。#6720 报的场景是显式每分钟限流被算成小时级冷却：上游回
rate_limit_error、带 Retry-After: 30，同时带一个四小时之后的 Anthropic-Ratelimit-Unified-Reset，而 unified 状态头是空的14。旧口径错在最后半句。v8.0.32 第 196–197 行把「unified 状态头为空、5 小时与 7 天窗口又都不健康」也算成拒绝窗口，那个四小时后的 reset 于是进了候选，最后取的是最晚的一个15。
新函数要同时满足三条才走窄口径：响应体正好是那三句每分钟限流文案之一、没有任何非空配额状态头、
Retry-After 是单一且不超过窗口上限的值。三条齐了，它把 unified reset 头删掉再走旧解析，剩下的就是那 30 秒16。冷却变短有代价。这一条只对显式的每分钟限流生效，真正的额度拒绝还是长冷却；被窄口径放行的请求会更快回到上游，压力跟着回去。
还在 v8.0.32 上的，撞上这种 429 之后一张凭证能挂四小时，止损还是那个管理接口：
POST /v8/management/routing/cooldown/reset，请求体带 auth_index，空值回 400、找不到回 40419。
四、v8.0.32 里两处还没人修的凭证窗口
#6733 说的是管理端改凭证字段的写法：先读一份副本、改完整体替换，读发生在锁之前。窗口里如果正好有一次 token 刷新落地，这份旧副本会把它盖回去，内存和磁盘一起盖20。
#6734 说的是凭证文件原地改写（先截断、再写）。全量扫描读到写了一半的文件时，这份文件不产出任何凭证，随后被当成删除、把账号注销掉，直到写入方自己的文件事件把它加回来21。
两条都来自同一位报障人，都写明只做了源码追踪、没有对上游实测，也都没有给出发生频率。
所以这两条当线索看。今天能做的也有限：改凭证字段别和刷新挤在一起，慢存储上这个窗口更宽；同步工具正在写 auth 目录的时候，全量扫描先停一停。
自己打补丁可以等一等，这两条连上游都还没人复现。
五、版本与其余动态
窗口里另外三条，一条一条看是否与自己有关。
#6731 是访问日志的注入：日志行用
%s 拼解码后的请求路径，%0A 进来就是真的换行，一个请求能在日志里变成两行，第二行全由请求方决定。访问日志是第一个全局中间件，未匹配的路由也记，所以不需要任何凭证22。#6732 是 Gemini 工具清洗的三处问题：本地
$ref 被替换成「See: X」的提示、$defs 随后被删；Antigravity 的工具声明把 ref 解析到了外层的 carrier 上；default、enum 这类字面量被当 schema 遍历，作者举例 default 里的 {"title":"Report","format":"pdf","id":7} 发出去只剩 {"format":"pdf"}23。#8191 修的是
passthrough_body=true 的规则仍然只透传 message：OpenAI 原生路径把错误重建成 {type:"upstream_error", message}，code 和 param 都丢了，靠 error.code 分流的客户端认不出 previous_response_not_found 这类错误。6 个文件 +273/−18，open、clean，范围只写了 OpenAI 原生路径24。codex2api 只有一条旧单被顶起：#787 是 10 月 15 日凌晨开出的树莓派 Zero W 内存与 CPU 占用问题，窗口里补了一条在 v3.1.1 上的观测——两个活跃 API key 时内存回到 95–105MB，CPU 每次请求仍有 80% 以上、持续 1 到 3 秒，作者认为比 v3.0.6 及更早版本差25。codex-proxy 这个窗口里没有新开或更新的条目。
上游状态没有新事件：OpenAI 全绿、活动事件 026；Anthropic 全绿、10 月 18 日无事件27；Google Cloud 的事件列表仍是 7 条，最近一条还是 10 月 8 日开始的那次 Cloud Storage 延迟28。
Codex 额度侧今天还没有新的重置，累计 54 次全局重置、10 次 banked，节奏约每 4 天一次。这个页面上的两处时间对不上：首页头条写最近一次已验证是 10 月 15 日 14:13（北京），同一页的监控行又记着 10 月 18 日 04:41（北京）的一次。上一期已经写过它几处口径不一，这期只取一件事——今天没有新的29。
今晚按这个顺序：先确认你的易支付网关有没有
api.php，没有的话看是不是已经有一批订单卡在 502 上；再看 /v1/models 有没有掉模型；最后把这次窗口里两笔 dev 修复记下来，等下一版上。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI dev 提交记录
github.com
- 6sub2api PR #8192
github.com
- 7sub2api v0.2.17 easypay.go
github.com
- 8sub2api issue #8171
github.com
- 9CLIProxyAPI 提交 f75ea073
github.com
- 10CLIProxyAPI issue #6718
github.com
- 11CLIProxyAPI dev service_auth.go
github.com
- 12CLIProxyAPI v8.0.32 service_auth.go
github.com
- 13CLIProxyAPI 提交 db1bab01
github.com
- 14CLIProxyAPI issue #6720
github.com
- 15CLIProxyAPI v8.0.32 claude_ratelimit.go
github.com
- 16CLIProxyAPI dev claude_ratelimit.go
github.com
- 17CLIProxyAPI PR #6719
github.com
- 18CLIProxyAPI issue #6720 评论
github.com
- 19CLIProxyAPI v8.0.32 quota.go
github.com
- 20CLIProxyAPI issue #6733
github.com
- 21CLIProxyAPI issue #6734
github.com
- 22CLIProxyAPI issue #6731
github.com
- 23CLIProxyAPI issue #6732
github.com
- 24sub2api PR #8191
github.com
- 25codex2api issue #787
github.com
- 26OpenAI Status
status.openai.com
- 27Anthropic Status
status.anthropic.com
- 28Google Cloud incidents.json
status.cloud.google.com
- 29codex-reset.com
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.