OpenAI 全网 503 时，为什么你的中转站还能用
OpenAI 出现大面积 503 时，官方网页端和 Codex 任务集体中断，却有人发现自己的第三方中转接口照常返回结果。这篇文章解释故障期间到底发生了什么、为什么「官方挂了它独活」值得警惕，并给出判断上游真伪、保护长任务、选择合规调用方式的检查清单。
OpenAI 服务出现大面积不可用的时候，最先暴露问题的往往不是官方状态页，而是各种第三方接口。有人打开网页端，对话一直卡在思考状态；有人正在跑的 Codex 任务跑到一半直接断开；也有人翻出状态页，才发现整个平台都在报错。于是第一反应几乎都是「是不是我的账号废了」「是不是我的网络有问题」。
真正有意思的是故障之后的第二幕：一部分人发现自己平时用的第三方中转接口居然一切正常。本来是打算笑话别人接口不稳的，结果等官方恢复慢吞吞、自己的接口还在流畅返回时，才意识到该被笑话的可能是自己。这篇文章就把这件事拆开讲清楚：故障期间发生了什么，为什么会出现「官方全挂、它独活」的情况，以及日常该怎么降低这类中断带来的损失。
故障时的典型表现
从各方反馈汇总来看，这一轮故障大致有几种表现：
- 网页端：能打开、能输入，但回复一直处于等待或思考状态，最终超时或报错。
- API 调用：返回 503 一类的服务不可用错误，重试多次仍然失败。
- Codex 类长任务：已经开始执行的任务在中途断开，上下文丢失，需要重新发起。
- 恢复时间不一致：有人十几分钟后恢复正常，有人过了很久仍然感觉响应很慢，一轮对话要跑很久。
值得注意的是，同一时间段里也有人表示自己一直正常使用。这通常不是「官方在区别对待」，而是因为同一个平台背后有多个入口、多组网关和多层缓存，不同账号、不同区域、不同客户端命中的节点未必相同，恢复顺序自然也有先后。
还有一个容易被误判的点：故障期间恰好在做额度相关操作的用户，会本能地怀疑是操作导致的异常。实际上，平台级故障和个人额度是两件事，判断依据应该是官方状态页上的公告，而不是自己的使用感受。至于故障后是否会给出额度补偿或重置，这属于平台自己的运营决策，没有稳定规律，以官方最新公告为准，不要把它当成可以预期的收益。
为什么官方挂了，它却还在返回结果
这是整件事里最值得琢磨的部分。「官方全线报错，我这还能用」并不必然等于造假，但确实是一个需要认真对待的信号。常见的解释有这么几类：
- 重试与队列在替上游兜底。 上游短暂失败时，中间层可以自动重试、排队或切换到备用线路，用户侧看到的是成功返回，但延迟会明显变长。故障期间「还能用但很慢」多半属于这一类。
- 缓存命中。 对相同或高度相似的请求直接返回此前的结果。日常问答不容易察觉，一旦问到时效性内容或让它执行带副作用的操作，问题就会暴露。
- 路由到了别的地方。 有些服务同时接了多家上游，主线路不可用时自动切到其他模型或其他供应商。功能上没断，但你拿到的已经不是你以为的那个模型。
- 本来就不是官方模型。 用更便宜的模型冒充、用规则或小模型处理简单请求、只在高价值请求上真调用，都是成本更低的玩法。这类服务平时看起来「又快又便宜」，只有在官方出问题、对照之下才显得异常。
反过来也要说一句公道话：不能仅凭一次故障就给某个服务定性。上游恢复过程中，各家网关的重试策略、超时设置、备用池配置都不一样，短时间内的表现差异是正常的。判断要看长期、多维度的证据。
判断上游是否真的在调官方模型
下面这份清单能帮你提高判断的准确度，但请注意：没有任何单一方法能给出百分之百的结论，只能作为交叉验证。
| 检查项 | 具体做法 | 需要注意的地方 |
|---|---|---|
| 状态页对照 | 出问题时先看官方状态页，记录错误码与时间 | 状态页本身也可能延迟更新 |
| 错误码特征 | 观察限流、超时、参数错误的返回格式是否与官方文档一致 | 中间层可能统一包装过错误信息 |
| 响应字段 | 检查返回体里的模型标识、请求 ID、用量统计是否符合预期 | 字段可以被伪造，只能作为弱证据 |
| 能力探测 | 用长上下文、多步工具调用、结构化输出等需要真实模型能力的任务测试 | 便宜的模型也能勉强完成简单任务 |
| 用量一致性 | 对比同样的输入输出的 token 计量，是否与官方分词方式吻合 | 偏差大是强信号，吻合不代表没问题 |
| 延迟分布 | 观察响应时间的波动是否自然 | 过于稳定或异常快都值得怀疑 |
| 故障期表现 | 官方整体不可用时是否仍能稳定返回 | 单独看不成立，需要结合其他证据 |
如果想自己动手做基础连通性检查，可以用一行命令确认请求是否真的到达官方端点、耗时多少，注意把密钥放在环境变量里，不要写进命令历史：
curl -sS -o /dev/null \
-w "http=%{http_code} time=%{time_total}s\n" \
https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
如果这个请求在故障期稳定失败，而你换一个第三方地址却能秒回，那就把这条记录留存下来，作为后续判断的参考。
任务跑到一半断了，怎么把损失降到最低
比起争论谁真谁假，更实际的问题是：下次再遇到类似中断，怎么让正在跑的任务不至于从头再来。
把长任务拆成可恢复的小步。 让模型按步骤执行，每完成一步就把中间结果写入文件或数据库，记录已完成到哪一步。恢复时读取最后一条成功记录，从下一步继续，而不是重跑全部。
给调用加上有上限的退避重试。 只对限流和 5xx 类错误重试，遇到参数错误、鉴权失败不要重试，否则只是浪费时间。
import random, time, httpx
def call_with_retry(fn, max_attempts=6, base=2.0):
for attempt in range(max_attempts):
try:
return fn()
except httpx.HTTPStatusError as e:
if e.response.status_code not in (429, 500, 502, 503, 504):
raise
if attempt == max_attempts - 1:
raise
time.sleep(min(60, base ** attempt) * (0.5 + random.random()))
注意重试的副作用。 如果任务里包含写文件、发请求、提交变更这类操作，重试前要确认幂等，否则一次故障可能换来重复执行。
保留完整日志。 把每次请求的时间、状态码、耗时、使用的模型标识都记下来。这既是排查故障的依据，也是日后核对供应商是否言行一致的材料。
中转与共享额度的风险，以及更稳妥的替代
围绕第三方接口，有几件事需要提前想清楚，而不是等出了问题再后悔：
- 账号与额度风险：多人共用、来源不明的凭证一旦触发平台的风控或违规判定，可能连累正常账号，申诉成本很高。
- 数据风险：请求内容会完整经过中间层，涉及代码、密钥、业务数据的场景要格外谨慎。
- 服务连续性风险：这类服务没有可用性承诺，跑路、突然涨价、突然换模型都可能发生，且没有追责渠道。
- 模型真实性风险：掺水、替换、缓存都会直接污染你的评测结论和线上效果。
在合规路径上，优先考虑官方 API 或官方订阅、企业版方案；需要多云容灾时，选择有明确服务协议的模型托管服务；对数据敏感的场景，评估自部署开源模型。国内网络环境下访问境外服务的稳定性问题，应当通过正规的接入方式解决，而不是想办法绕过平台限制。
长任务真正需要的是稳定的运行环境
回过头看，很多「任务断了」的痛苦并不来自模型本身，而来自运行环境：本机休眠、网络抖动、终端被关掉、进程被系统回收。如果你的工作流需要连续几小时甚至整天挂着跑，可以考虑把任务放到一台长期在线的机器上，通过远程连接操作，本地只负责查看结果。例如整台 Mac mini 放在新加坡机房、按月租用、远程连接的独享远程 Mac，网络环境相对稳定，适合长时间运行 Codex、Claude Code 这类需要持续在线的工具。这只是可选做法之一，日常短任务用本地环境完全够用。
小结
一次大规模 503 本身并不可怕，可怕的是它顺带暴露出来的东西：你对自己依赖的接口了解得不够。
- 遇到中断先看官方状态页，别急着怀疑账号和网络。
- 「官方挂了它独活」不是定罪证据，但值得记录并交叉验证。
- 长任务要拆步、留检查点、有上限地重试，并保证重试幂等。
- 对第三方接口保持基本的风险意识，重要业务走有承诺的合规通道。
- 补偿、额度重置这类事情没有稳定规律，以官方最新公告为准。
