OpenAI 返回 503 / 排队 / 超时
先分清中断、限额和配额
OpenAI 的 ChatGPT、Codex 或 API 返回 503、429 或超时，不一定是 key 坏了。先打开 status.openai.com，再决定是等、换模型还是换端点。订阅暂停和额度烧光是另外两件事。
更新于 2026-09-11
四个不该混在一起的信号
上游容量或路由
503、502、status 页上的 elevated errors，通常不是你的 prompt 写错。重试要退避，不要同步打满。
你的速率或并发
429 是账号或组织自己的速率窗。降并发、拉开间隔，比换模型更对症。
账期或 credits 见底
窗口是绿的、请求仍被拒，更像额度而不是中断。那一页是 /gpt-6-astra-quota-burn，不是本页。
先看官方状态页
status.openai.com 写 fully operational 时，优先查自己的 429 和配额，而不是默认「全网挂了」。
这类故障该怎么处理
OpenAI 侧的报错、排队和超时会反复出现，不绑定某一次事故编号。处理顺序固定：先看 status.openai.com 当前横幅和 history 里最近一条事件标题，再看 HTTP 状态码是 5xx 还是 429，最后才决定等、降并发，还是把同一把 key 指到别的模型家族。ChatGPT 网页打不开，不等于 API 一定同时挂；Codex 报错，也不等于 Responses API 一起挂。
2026-09 这几场能核到的事件
2026-09-03，公开报道写一次多组件中断打到 ChatGPT 与 Codex，至少 15 service areas，约 14:56 UTC 状态页翻成 degraded performance。2026-09-04 东部时间 18:30，The New Stack 更新称 GPT-6 Astra 已向包含该模型的付费用户在 ChatGPT 开放。2026-09-10 history 上有 Elevated errors affecting ChatGPT Work。2026-09-11 抓取 status.openai.com 时页面写 We’re fully operational，并称 not aware of any issues affecting our systems；llmlatency.dev 同日写 Last verified September 11, 2026。
时间线
2026-09-03 GPT-6 Astra 发布日前后，ChatGPT 与 Codex 出现多组件中断；报道写至少 15 service areas，状态页曾显示 degraded performance（约 14:56 UTC）。
2026-09-04 东部时间下午 6:30，公开报道更新：GPT-6 Astra 已向所有包含该模型的付费用户在 ChatGPT 上开放。发布日当天的「锁在门外」和「服务中断」不是同一件事。
2026-09-10 status history 留下 Elevated errors affecting ChatGPT Work。2026-09-11 再打开状态页，文案是 fully operational。单次事件已经结束，排障步骤还在。
已确认 vs 不要写成事实的
能在状态页或报道里核到的（截至 2026-09-11）
截至 2026-09-11：status.openai.com 写 fully operational / not aware of any issues affecting our systems；history 里有 Elevated errors affecting ChatGPT Work；2026-09-03 有 ChatGPT 与 Codex 的多组件中断报道（15 service areas、约 14:56 UTC degraded performance）；2026-09-04 有 Astra 对付费用户铺开的更新。这些都带日期，可以回查。
传闻，以及官方没说的
把 2026-09-03 的中断说成「GPT-6 把全网打挂到现在」没有状态页支持。把 ChatGPT Work 的 elevated errors 说成「API 全线停」也不成立。未证实：下一次容量事件何时来、是否会再叠加订阅暂停。X 上的截图只说明有人在讨论，不证明全局故障。
等恢复，还是换路
停在 OpenAI 等横幅变绿
适合 status 页明确在报 incident、而你的负载可以停几十分钟的情况。不适合 24/7 agent：等的成本高于换模型。
同一把 key 切到别的家族
适合 HTTP 5xx 持续、或 ChatGPT 网页和 API 不同步的情况。把 Claude Code 指到 ANTHROPIC_BASE_URL，或把 Codex CLI 指到兼容端点，继续跑不是 OpenAI 的模型。
排查三步
第一步：打开 status.openai.com ，记下当前横幅和 history 最新标题，不要只看社交媒体转发。第二步：看响应码。5xx 用指数退避；429 降并发；没有 HTTP 码只有「usage limit」走配额页。第三步：若 status 已绿而你这边仍失败，查本地代理超时和 key 权限。需要换路时，Claude Code 设 ANTHROPIC_BASE_URL 与 ANTHROPIC_AUTH_TOKEN，Codex CLI 走 OpenAI 兼容 base URL。
在 QCode 上具体怎么做
先完成注册并复制控制台里的 key。Claude Code：ANTHROPIC_BASE_URL = https://api.qcode.cc ，ANTHROPIC_AUTH_TOKEN 填这把 key，步骤见 anthropic-base-url-setup-guide。Codex CLI：把 OpenAI 兼容 base URL 指到同一主机，model 先用 gpt-5.6-sol 做通路测试（官方现价 $4 / $20，促销至少到 2026-11-21），再按任务切 gpt-6-astra 或 Claude 家族。下一步：发一条非流式小请求，确认 HTTP 200 且回显 model 对得上。
常见问题
ChatGPT 网页打不开，API 一定也挂了吗？
不一定。状态页把 ChatGPT、Codex、APIs 分成不同组件。2026-09-10 的 ChatGPT Work elevated errors 不等于 API 组件同时红。以 status.openai.com 的分项为准。
503 和 429 有什么差别？
503 / 502 多半是上游容量或网关，重试要退避。429 是你的速率或并发，降并发比换模型更对症。两者都不是「key 被盗」。
这和 Astra 额度烧得快是一回事吗？
不是。额度是 credits 单价和 5 小时窗，见 /gpt-6-astra-quota-burn。本页处理的是可用性：status 红、5xx、排队、超时。
status 已经绿了，我这边还是超时，怎么办？
先查本地代理、CDN 和客户端超时是否短于模型生成时间，再查 key 是否只有部分端点权限。全局故障在 status 绿了之后就不再是第一假设。
QCode 能让 OpenAI 官方恢复得更快吗？
不能。我们改不了上游容量。能做的是同一把 key 切到仍在响应的模型家族，让你的任务先跑完。
Codex CLI 超时，要不要立刻换订阅档？
先看 status 和 HTTP 码。订阅档解决不了 5xx。若确认是配额，再考虑换模型或换计费路径，而不是先升级 ChatGPT 订阅。
信息来源
当前状态文案：status.openai.com（2026-09-11 抓取，fully operational）。事件标题：status.openai.com/history（Elevated errors affecting ChatGPT Work）。2026-09-03 多组件中断：Crypto Briefing。Astra 对付费用户铺开：The New Stack 2026-09-04 更新。第三方探测日期：llmlatency.dev Last verified September 11, 2026。
相关阅读
Claude 529 Overloaded 怎么处理
另一家上游的容量错误：指数退避，而不是改 prompt。
GPT-6 Astra 为什么这么费额度
可用性中断和 credits 倍率是两件事，别用错排查页。
Stream closed before completed
流式中途断开的四种成因，和 5xx 全局故障不是同一类。
本页是排障说明，不是 OpenAI 官方 status 的镜像。以 status.openai.com 当前文案为准。QCode 不能加速上游恢复，也不转售 ChatGPT 订阅。