ChatGPT 频繁出现「消息流中的错误」：一次从网络排查到暂停长任务的记录

记录日期：2026 年 9 月 23 日。本文是个人使用和排查记录，尚未确定故障根因。

从 9 月 22 日开始，我使用 ChatGPT 时频繁遇到「消息流中的错误」（Error in message stream）。之前同一套工作方式基本正常，这两天却接连中断。

9 月 23 日下午，情况尤其明显：不同会话反复失败，刷新后一度加载不出来，甚至独立审核任务也没能幸免。

我使用的是 ChatGPT Plus、GPT-5.6 Sol High、Ubuntu 和 Firefox，同时连接 Remote Desktop Commander（MCP），处理本地文件、终端操作以及需要较长上下文的任务。

今天我把网络测试、开发者工具里的现象和两组真实任务的数据整理出来，既作为自己的排障记录，也供遇到类似问题的人参考。

一、从偶发中断变成反复报错

今天多个独立会话先后出现了相似故障。有的在连续网页搜索之后出错，有的已经读取正式文件、执行多轮 MCP 调用，最后却没能返回结果。

有时连续四五次重试仍然失败；有时一个新请求执行了没多久就突然中断。

更令人困扰的是，同样的任务并非每次都失败。一次独立审核在之前多次报错后，曾连续执行约八分钟并成功完成。但随后其他长任务又发生中断。

我没办法仅凭任务运行了几分钟，就判断它是否会成功。

有时页面还会出现系统正在进一步处理请求、建议改用响应更快的模型的提示。

然而，即使等待，也不能保证本次任务最终会成功。正式工作又有固定的模型和质量要求，我不想为了绕过报错而随意降级模型。

二、我先怀疑家里的网络

9 月 23 日下午，家里有两个人正常上网，我最初怀疑网络拥塞使长连接不稳定。不过，9 月 22 日家里只有我一个人时也发生过错误，不能仅凭使用人数就下结论。

我在 Ubuntu 上测试了到路由器、Cloudflare DNS 和 ChatGPT 的连接；随后给长期未重启的光猫断电重启，再做了一轮对照。

随后我又连续执行了十次 curl https://chatgpt.com/。十次均建立了 HTTPS 连接并返回 HTTP 403，耗时约 0.59～3.43 秒，没有连接超时。

这里的 403 是命令行请求被拒绝，不能据此认定 ChatGPT 网站故障，也不能证明登录后的长时间流式响应正常。

1.1.1.1 的 ICMP 丢包值得注意，但 8.8.8.8 同期没有丢包，因此尚不能证明整个家庭公网连接都有同样的问题，更不能把 ChatGPT 的故障直接归咎于另一位家人上网。今天我没有要求对方停止正常使用网络。

三、Firefox：HTTP 200，也可能最终显示消息流错误

为了弄清楚问题发生在哪里，我打开了 Firefox 的网络监视器，开启「保留日志」，观察下一次错误。

截图里，不少请求显示 HTTP 200 或 202，页面却已经出现「消息流中的错误」。

这不矛盾：某个请求成功返回，不等于模型的整个长时间消息流已经完整完成；这些状态码也可能属于其他后台请求。

Console 中还反复出现了另一种错误：

ERROR [Statsig]
A networking error occurred during POST request
Error: Timeout of 10000ms expired.

ERROR [Statsig]
A networking error occurred during POST request
Error: Timeout of 10000ms expired.

出错的请求指向 chatgpt.com/ces/v1/rgstr 一类地址。

这个超时是实际观察到的异常，但它涉及 Statsig 相关请求，并不是已经确认失败的模型生成请求。

我还没有获取到足以区分浏览器、网络路径和服务端执行问题的完整生成流证据。

四、一次 60 份内容的实验，被反复中断拖住

当天我恰好正在比较两种大批量结果交接方式。两组各有 60 份完整内容，模型配置相同，正式输入都使用完整的 Generation ZIP。

实验的本意是比较浏览器下载 ZIP 与 Remote Desktop Commander 成组传输的人工交接和工具调用成本，而不是比较两种语言的生成能力。

A 组：普通 ZIP 传输成功

A 组的生成过程比较顺利。

实际生成耗时 6 分 28 秒，60 份原始结果压缩后为 26,431 字节；手动下载 ZIP 一次，随后完成正式 result-pack → import → process，60/60 通过自动验证。

Desktop Commander 月度 calls 从 4,107 增加到 4,113，共计 6 次。

这里的 calls 是该实验时段的读数，不应与所有其他任务的用量混淆。

B 组：还没真正测试传输，生成就反复失败

B 组原计划采用 RDC 成组传输，希望减少人工下载 ZIP 的步骤。

结果它在生成阶段连续三次出现消息流错误，根本没有进入正式的 RDC 成组写入环节。

随后，我专门执行了一次恢复检查，核对正式 batch、临时目录、下载目录和已经保存的文件。

检查结果令人失望：全部 60 份正式输入仍在，但未找到已保存的隐藏 staging、普通输出 ZIP、正式 raw responses 或验证证据；可复用的完整输出是 0/60。

此时 calls 已增加到 4,119，但这些增量包含故障和恢复环节，不能算作 RDC 写入成本。

为了避免重复生成却再次丢失成果，我又尝试调整执行方法：在同一次生成过程中，每完成约 15 份内容，就通过 RDC 成组保存到隔离目录。

可后续仍发生消息流错误；最后一次尝试的浏览器截图显示，任务依旧在生成过程中中断。

由于还没有取得那次尝试之后的完整持久化检查结果，我没有把它记作成功输出，也没有执行正式导入。

这次实验至少让我看到一个实际成本：如果一个长任务的结果只在最终回复时交接，消息流中断可能让此前的生成工作无法复用。

但 B 组发生在传输之前的故障，不能证明 RDC 传输方案不可靠；对照实验目前也没有完整结果。

五、其他用户也报告过类似现象

我在 V2EX 发帖询问，起初没有回复，后来有用户表示遇到过类似错误，也有人提到近期 ChatGPT 的稳定性问题。

这至少说明类似现象不只出现在我这里，但还不能证明所有人的问题由同一个原因引起。

六、暂时停止重复重试，保留已经完成的工作

折腾到傍晚，我决定当天暂时停止继续尝试 B 组。

反复运行完整任务，无法保证成果能被持久保存，还会增加人工恢复和额度成本。已经通过正式检查的成果继续保留；对尚未完成的结果，则以实际文件和验证证据为准，不凭聊天界面上的进度文字认定成功。

截至写作时，我仍不能确定根因是 ChatGPT 后端负载、模型与工具的执行协调、消息流恢复机制，还是我自己的网络或代理路径。

网络测试和控制台记录只能帮助缩小范围，不能替代正式故障诊断。

对依赖 AI 长时间执行的工作流来说，模型能否生成高质量内容很重要，结果能否及时保存、故障能否安全恢复、重复尝试要付出多少代价，同样重要。