“消息流发生错误”会在 ChatGPT 逐步传送回答的连接于回答完成前中断时显示。这种错误几乎不会由输入内容造成。大多数情况下，原因是 OpenAI 端过载、连接不稳定、浏览器扩展程序，或对话过长。重新生成回答可以解决大多数情况；如果仍无法解决，只要查看一次状态页面，就能判断问题是否出在自己这边。
错误
메시지 스트림에 오류가 발생했습니다
(같은 장애의 다른 표현: “스트리밍이 중단되었습니다. 전체 메시지를
기다리는 중”, “Hmm...something seems to have gone wrong.”
증상은 동일합니다 — 답변이 도중에 멈추고 끝까지 생성되지 않습니다.)原因和解决方法一览
| 原因 | 解决方法 |
|---|---|
| OpenAI 端过载或服务故障。会同时出现在所有套餐中，Plus 和 Pro 也不例外。如果每隔几分钟反复发生，最有可能就是这个原因。 | 在 status.openai.com 查看正在发生的服务故障。故障期间，无论怎么修改自己这边的设置都不会改变结果，等待是唯一的解决方法。 |
| 连接不稳定：Wi-Fi 与 LTE 切换、VPN 或公司代理服务器、移动信号微弱。流式传输会长时间保持同一个连接，因此即使普通页面能正常加载，连接也可能中断。 | 关闭 VPN 和代理，并切换到其他网络连接（Wi-Fi ⇄ 移动数据）后重试。 |
| 浏览器环境：会干扰页面的扩展程序、过期的缓存、已过期的会话。 | 在无痕窗口中重试。如果那里正常，原因就是扩展程序或缓存——关闭扩展程序、清除网站数据，然后重新登录。 |
| 对话过长或附件太大。因为每一轮都会重新发送完整对话，生成时间会变长，中断概率也会随之上升。 | 只整理要点并移到新对话中。不要一次性上传大文件，请拆分后再发送。 |
前 90 秒可以做的三件事
重新生成回答 → 刷新页面（如果使用应用，则完全退出后重新启动）→ 退出登录后重新登录。一次性中断可以通过这三项中的一项解决，而一次性中断是常见情况。相反，如果每次都在同一位置停止，则表明下列某个具体原因正在起作用。
先判断问题是否出在自己这边
这是其他解决问题的文章会跳过、却最能节省时间的一步。打开 status.openai.com。如果显示正在发生服务故障，调整自己这边的设置不会改变任何结果，除了等待别无他法。如果没有显示任何问题，原因就在自己的环境中，下一步会帮助缩小范围。在修改设置前先做这项检查，就不会在服务故障期间花 20 分钟清除缓存。
从外部开始，逐层缩小原因范围
按以下顺序操作，因为每一步都能排除它之前的所有可能性：① 关闭 VPN 和代理 ② 在无痕窗口中打开（一次排除扩展程序和缓存）③ 换用其他浏览器或设备 ④ 更换网络连接。在哪一步恢复正常，原因就对应哪一步。如果只在长对话中出错，这四项都不是原因，只把要点移到新对话中是最可靠的方法。
面向开发者：API 中也会发生同样的中断
使用 stream: true 调用 API 时，同样的故障会表现为 Server-Sent Events 连接在没有 finish_reason 的情况下结束。HTTP 状态为 200——因为发送响应头时一切正常——因此只检查状态码无法发现这种故障；负载升高时，还会同时出现 429 和 529 overloaded_error。要让系统能够应对这种情况，需要做三件事：(1) 将没有 finish_reason 就结束的流视为需要重试的对象，而不是完整回答 (2) 对 429、500、529 使用指数退避和抖动进行重试 (3) 如果经过代理，检查 idle timeout 并关闭响应缓冲——启用缓冲的代理会把正常的流变成长时间停顿。要判断原因，先绕过代理直接尝试流式传输：
# 프록시를 거치지 않고 직접 스트리밍해 어디서 끊기는지 확인한다.
curl -N https://api.kunavo.com/v1/chat/completions \
-H "Authorization: Bearer $KUNAVO_API_KEY" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","stream":true,
"max_tokens":300,
"messages":[{"role":"user","content":"1부터 20까지 천천히 세어줘"}]}'如果你通过 Kunavo 调用
Kunavo（AI API 网关）的设计以这类临时流式传输失败会发生为前提。如果同一模型配置了多个上游通道，首次尝试失败时，会在同一请求中自动切换到其他通道并重试，因此上游的临时不稳定会变成“稍慢一点的成功”，而不是错误。失败的请求不会计费。你可以用一个 API 密钥调用 GPT 和 Claude；当某个模型过载时，只需更换模型名称即可绕过。 有关流式传输情况下的重试和退避模式，请参阅以下文章： LLM API 流式传输错误.
常见问题
“消息流发生错误”是我这边的问题吗？
几乎不是。这条消息表示传送回答的连接在完成前中断。输入的内容不会导致此错误。原因是 OpenAI 端的负载、网络不稳定、浏览器扩展程序或已过期的会话，或者对话过长，导致响应超时。
重新生成后仍然不行怎么办？
先查看 status.openai.com——服务故障期间，自己这边无能为力。如果没有故障，请换用其他网络连接，在无痕窗口中打开。这一次测试可以同时排除扩展程序、缓存和平时使用的网络连接。如果在那里正常，就逐项恢复，找出再次出错的环节。如果在哪里都不行，而且只在某个特定的长对话中出现问题，请只把要点移到新对话中。
其他 AI 也会出现同样的错误吗？
这条消息的措辞来自 ChatGPT，但 Claude 和 Gemini 接收流式回答的结构也相同，因此连接中断时会发生同类错误。在 Claude 中，会显示无法完整生成回答的消息；直接调用 API 时，会表现为没有 finish_reason 就结束的 SSE 流，或在负载升高时出现 529（overloaded_error）。
为什么长对话中更容易出现这种情况？
因为每一轮都会重新发送整个对话，对话越长，就会在同一个保持打开的连接上生成越久。连接保持打开的时间越长，代理超时、网络切换和上游瞬时问题介入的机会就越多。通常，只总结要点并开始新对话，比修改浏览器设置更有效。