9 月 23 日，我写过一篇《ChatGPT 频繁出现「消息流中的错误」：一次从网络排查到暂停长任务的记录》，记录了从 9 月 22 日开始，ChatGPT 在长任务、网页搜索和 Desktop Commander 工具调用中频繁中断，以及当时做过的网络排查与任务恢复尝试。
上一篇文章：
当时其实已经积累了一些截图和本地诊断记录，也向 OpenAI Support 提供过故障时间、会话信息、运行环境等材料；只是还没有按照官方后来提出的要求，提交一份恰好覆盖故障发生过程的 HAR 网络记录。这次是接续上一篇的最新进展，而不是从零开始排查。
收到官方回复后，我才决定提前开启网络捕获
在继续沟通后，OpenAI Support 回复了原工单，明确希望获得一份在故障发生时捕获的 HAR。客服表示此前提供的截图与环境信息已经收到，不需要重复发送，也不希望我为了复现故障而反复执行额外测试。
因此，今天我按照邮件给出的步骤，提前打开 Firefox 开发者工具的「网络」面板，开启「持续记录（Persist Logs）」，并在准备正常使用 ChatGPT 时保持记录。之前积累的诊断材料仍然有用；这次要补的是官方特别要求的、带有故障时序的 HAR 文件。
今天截至傍晚，我注意到两次「消息流中的错误」。第一次出现时没有完成所需的网络捕获；第二次发生时，网络记录已经开启。
古吉拉特语翻译进行到第三批时，再次遇到中断
第二次故障发生在 A Tour of Go 多语言翻译项目的古吉拉特语（Gujarati，gu-IN）工作中。当时正在处理第三批 19 个 Example 的正式翻译输入，使用的是 GPT-5.6 Sol High。
ChatGPT 页面再次出现红色的「消息流中的错误」。这一次，我没有急着刷新页面或连续点击「重试」，而是先保留开发者工具中的现场。
从这次控制台截图可以看到，多条请求 ChatGPT 后端接口的 XHR 返回了 HTTP 429，同时还有 CSP 错误和 Source Map 404 等信息。429 通常意味着请求受到频率限制，但不能仅凭控制台截图就断定它导致了消息流中断；真正的请求时间线和响应细节，还要结合 HAR 由支持团队分析。
按官方要求保存 HAR 和控制台日志
这次之所以提前抓包，是因为 Support 在邮件中提出了明确要求：在正常使用过程中保留网络记录，遇到下一次故障时导出一次受影响会话的 HAR，并回复原工单。
我随后在 Firefox 的网络面板中选择「所有内容另存为 HAR」，保存了故障发生时的网络活动。保存前没有先刷新页面，也没有清空网络记录。
为了让客服能直接检索错误信息，我还切换到「控制台」，通过「将所有消息保存为文件」导出了文本日志，而不只保留截图。
本次得到的两个文件分别是：
chatgpt.com_Archive [26-09-26 18-36-51].har，约 31.9 MB；console-export-2026-9-26_18-40-16.log，包含控制台错误、警告及相关请求记录。
这里的时间均为北京时间（UTC+8）：HAR 文件保存于约 18:36，控制台日志保存于约 18:40。
HAR 超过 Gmail 限制，改用云端硬盘共享
准备回复邮件时，我发现 HAR 大于 Gmail 的 25 MB 附件限制。Gmail 随即将较大的文件上传到 Google 云端硬盘，并在邮件中插入文件链接。
我没有将文件设置为「知道链接的任何人均可访问」，而是在发送时只向原工单的 Support 收件人授予查看权限。控制台日志也与 HAR 一起附在回复中。
最终，我在今天约 18:47 回复了原工单。邮件中说明了故障场景、捕获时间，以及控制台中出现的多次 HTTP 429，同时也明确表示目前尚不能确定这些响应与消息流中断之间是否存在直接因果关系。
今天的错误似乎少了，但还不能说已经修复
与此前频繁中断的几天相比，今天截至傍晚只观察到两次错误，主观感受确实有所改善。不过，这只是今天的使用记录，不代表故障已经解决，更不能据此推断 OpenAI 后端已经采取了某项修复。
这次真正取得的进展是：在官方明确提出 HAR 要求后，我提前做好捕获准备，并成功把一次受影响会话的 HAR 与控制台日志提交到了原工单。 此前的截图、网络排查和恢复经验也没有白费，现在终于补上了支持团队需要的关键材料。
接下来只需等待 OpenAI Support 的分析反馈。没有必要为了增加样本，刻意再跑一遍可能中断的长任务。等得到进一步回复，我再更新这篇故障追踪记录。