• One_day

    图片

    主楼
  • shiner

    上面都写很清楚了,是他们的负担太重了,处理不过来,把你的请求咔了,让你重新请求。

    #1
  • One_day

    晓得了,不过真的挺慢的,本来以为pro 会快一些,没想到…

    #2
  • CC-linuxdo

    可以试试美国的ip,之前看有帖子测试。

    oai的机房在美东是重要的流量承载地,出口IP 选这边的

    我也是pro,用的美西节点没遇到过这个问题

    #3
  • AeroLoong

    你这个成功率可以了,有时官方超负荷时会出现这种情况。正常。

    #4
  • hoshumu

    github.com/router-for-me/CLIProxyAPI

    Codex OAuth: hardcoded Originator: codex-tui gets gpt-5.6-sol requests load-shed (server_is_overloaded)

    已打开 08:29AM - 30 Jul 26 UTC

    已关闭 09:04AM - 30 Jul 26 UTC

    图片

    Crazytieguy

    gpt-5.6-sol requests through a Codex OAuth credential fail near-100% while gp…t-5.6-terra/gpt-5.6-luna work. The upstream response is HTTP 200 whose SSE stream immediately emits event: error with code: "server_is_overloaded", then response.failed (visible with request-log: true). Each failure also puts the auth into cooldown, so most client requests surface as 503 auth_unavailable, which makes this look like an auth problem.

    This is new behavior: the same setup ran cleanly 2026-07-20 through 2026-07-28, failures appeared in bursts during the early hours of 2026-07-29, and again throughout 2026-07-30 00:00–01:30 PT.

    A/B probes isolated the trigger to the Originator header, which is hardcoded to codex-tui (internal/runtime/executor/codex_executor_request.go):

    • Originator: codex_cli_rs (what the current Codex CLI sends): 4/4 success, even with a curl/8.7.1 User-Agent
    • Originator: codex-tui: immediate server_is_overloaded
    • Spoofing only the CLI User-Agent while keeping codex-tui: still fails

    Workaround: send an Originator: codex_cli_rs header on inbound requests — CLIProxyAPI forwards it in place of the default.

    Suggested fix: default the originator to codex_cli_rs, and/or make it configurable next to codex-header-defaults.

    Tested on v7.2.92; the constant is unchanged on current main (928478e4).

    server_is_overloaded 和 发送的 UA 有关,openai对于不同的接入有不同的优先级

    #5
  • 董炸淘

    这个好像不太行,我试过完全不管用。作者说的是对的,并非改成他的ua就能改善。

    反而是取消共享,账号静置1天后,能恢复。

    这个overloaded,八成就是风控了

    #6
  • hoshumu

    sub2api 和 CPA 最新的应该都是统一调用 codex-tui了,之前看有人问为啥新版本之后 codex 统计里客户端都变成 cli。这里应该说的是正常情况下,openai 服务端过载的情况下会区分优先级服务,不包括账号风控情况,账号风控的话啥都不好使。

    顺便说一下我们内部的 CPA 每天 1-2w 请求,这两周几乎没有 server_is_overloaded问题,成功率 99.7%,server_is_overloaded大概率是账号自己的问题

    #7
  • 董炸淘

    我在cpa里老早就是自己用的codex-tui这个ua,依然会overloaded,后来发现cpa一直内置就是这个ua,并且时不时更新版本号。

    在我这边一直同一个UA,并且出口也没变过,奇怪的很

    #8
  • hoshumu

    上面的 issue 里提了,默认开启 UA 伪装,可以通过 config 取消

    #9

发表回复

登录后回复