ChatGPT Plus 突然全员对话打不开，官方状态页还说一切正常

标题说得很清楚——从 2026 年 9 月 28 日下午 10 点（GMT-3）开始，Plus 用户们陆续遇到打开任何对话时直接报错的情况。官方状态页(status.openai.com)照旧绿灯，却无法掩盖实质性的服务中断。

问题表现

用户在不同设备、浏览器（包括 Chrome、Firefox、Edge）、网络环境下均尝试还原，结果一致：对话列表可以正常加载，但点击任意历史记录或新建对话时就会出现以下情况之一：

• 页面提示“无法加载，请重试”
• 对话内容显示为旧消息结尾，中间部分缺失
• 进入死循环“思考中...”并最终弹出 ChatGPT stream recovery polling timed out
• 暴露 404 / 500 / 503 等多种 HTTP 状态码
• 偶发性 429 Too Many Requests

这些错误并非固定路径触发，而是随机跳变，给用户带来的印象更像一次“降级雪崩”而非单点故障。

技术细节回放

结合一位 Plus 用户提交的 HAR 包（时间点为 2026 年 9 月 29 日 00:28 UTC），可以看到如下行为链：

1. GET /backend-api/conversations/{id} —— 返回 200，体积约为 12.9 MB，代表服务器端保存的对话数据尚完整；
2. POST /backend-api/f/conversation/resume —— 接连返回 404（cf-ray: a426de2ffc2c0cdd-SCL），表示恢复接口未命中；
3. 页面进入轮询模式，每隔约 12 秒重新请求一次 resume 接口，同时又重复下载整条对话，短短十分钟内达到 46 次重试、约 590 MB 流量；
4. 同时触发 POST /backend-api/conversations/batch 请求，返回体大小约为 69 MB，部分请求显示为取消或重复；
5. 开发者工具 Network 面板中并未显示 x-request-id，这使得问题排查难度加大。

用户已尝试如下措施，但皆告无效：

• 清除浏览器缓存与 Cookie，启用隐私模式；
• 更换设备（手机、平板、笔记本）及网络供应商；
• 关闭 VPN 后测试；
• 退出所有设备并重新登录；
• 多次刷新、多次重试，持续数小时。

尽管 help.openai.com 支持团队已将工单上报至专员，但至发稿前仍未分配编号，且数据导出功能预计需数天才能完成。

推测与猜想

尽管官方状态中心仍列为“正常运行”，但通过用户反馈与网络抓包分析，我们不难推断出背后可能隐藏几类潜在原因：

1. Resume 接口路由失效

POST /backend-api/f/conversation/resume 是 ChatGPT 前端在点击历史对话时第一时间调用的接口，用以加载之前的上下文。返回 404 意味着该接口可能因为部署异常、版本不一致或路径映射错误而暂时失效。换句话说，对话数据存在却无法被正确读取。

2. CDN 回源异常

Cloudflare Ray ID（a426de2ffc2c0cdd-SCL）指向美国南美圣地亚哥节点，表明用户请求曾被导向该区域的边缘服务器。若该区域的源站连接或缓存同步出现延迟，则极易导致 500/503 错误，尤其是在高并发场景下更为明显。

3. Stream Recovery 逻辑陷入死循环

当 Resume 接口失败后，前端默认启动 Stream Recovery 机制：轮询等待服务端恢复流式传输能力。然而，若服务端本身无法恢复，客户端将陷入无限重试 → 超时 → 再次重试的循环，造成巨量无效请求涌入，形成二次灾难性放大效应。

4. 配额管控误伤

部分用户报告收到 429 Too Many Requests 响应，说明 OpenAI 后端可能引入速率限制策略以防系统过载。但此类措施在非故障期间通常不会触发，故判断为灾后保护机制临时启用。

怎么处理？

面对这种情况，用户能采取的措施非常有限：

• 耐心等待服务恢复。由于故障涉及核心后端接口，只有 OpenAI 工程团队完成修复部署，才能根本解决问题。
• 避免频繁重试。每次失败都会增加服务端负载，加剧资源紧张局面。
• 记录关键日志信息。如时间点、cf-ray、请求 URL、状态码等，有助于客服更快定位问题。
• 尝试使用桌面 App 或移动端。部分用户反映 iOS 客户端尚能部分访问，或许 Web 端问题更为集中。
• 准备数据备份计划。如果工作依赖性极强，建议尽快申请数据导出，以防历史对话丢失。

尾声

这一次 ChatGPT Plus 的服务中断并不是一次简单的“抽风”，而是涉及路由、缓存、流控、配额等多个环节的系统性故障。在这样的背景下，即便是官方发布的应急通知也显得不够及时与透明。

对我们这些依赖它的用户来说，这不仅意味着工作效率的下降，更代表一种信任危机。希望这场故障尽快尘埃落定，OpenAI 也能在今后加强其监控与容灾能力，避免让用户再次陷入“明明打不开却查不到原因”的尴尬境地。