正价pro20经常这样有佬友遇见过没

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

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

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

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

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

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

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对于不同的接入有不同的优先级

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

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

这个overloaded，八成就是风控了

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

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

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