ChatGPT：消息流错误——原因与解决方法

当 ChatGPT 用于逐步传送响应的连接在响应完成前中断时，就会出现“消息流错误”。这几乎从来不是您输入内容导致的：常见原因是 OpenAI 侧过载、连接不稳定、浏览器扩展，或线程变得过长。重新生成响应可以解决大多数情况；如果不行，只需进行一次检查，就能判断问题是否确实在您这边。

错误

显示在 ChatGPT 线程中

Error en el flujo de mensajes

(La misma avería con otras redacciones: «Transmisión interrumpida.
 Esperando el mensaje completo», «Vaya...parece que algo ha salido
 mal.» El síntoma es idéntico — la respuesta se detiene a medias
 y nunca se completa.)

原因和解决方法一览

原因	解决方法
OpenAI 侧过载或发生故障。它会同时影响所有套餐，包括 Plus 和 Pro；当错误每隔几分钟重复出现时，这是最可能的原因。	查看 status.openai.com。发生故障期间，您在设备上做的任何更改都不会改变结果——等待就是解决方法。
连接不稳定：在 Wi-Fi 和移动数据之间切换、使用 VPN 或企业代理、移动信号较弱。流式传输会长时间保持单个连接开放，因此普通页面加载能够成功的地方，流式连接仍可能断开。	关闭 VPN 或代理，并通过其他连接重试（Wi-Fi ⇄ 移动数据）。
浏览器环境：某个扩展注入页面、缓存过期，或会话已过期。	在隐私窗口中重试。如果在那里正常，原因就是扩展或缓存——禁用扩展、清除网站数据，然后重新登录。
线程过长或附件过大。每次轮次都会重新发送完整对话，因此生成时间更长，也更容易中断。	将关键内容带到新聊天中。将大文件拆分，而不是完整地附加它们。

前 90 秒的三个操作

重新生成响应 → 刷新页面（在移动设备上，完全关闭应用后重新打开）→ 退出登录并重新登录。一次性的连接中断通常通过这三个操作之一即可解决，而一次性中断是正常情况。如果每次都在完全相同的位置停止，则说明原因是下面列出的某一具体问题，而不是偶发故障。

先判断问题是否在您这边

这是其他解决方案列表经常跳过的一步，也是最节省时间的一步。打开 status.openai.com。如果当前正在发生故障，任何本地调整都无法修复它，等待是唯一选择。如果没有显示故障，原因就在本地，下一步即可缩小范围。在调整设置前完成这项检查，可以避免在服务中断期间花二十分钟清理缓存。

从外到内隔离本地原因

按以下顺序操作，因为每一层都会排除前面的所有可能性：(1) 关闭 VPN 和代理；(2) 打开隐私窗口——一次性移除扩展和缓存；(3) 尝试其他浏览器或设备；(4) 切换网络。从哪一层开始恢复正常，原因就在哪一层。如果错误只出现在长线程中，四者都不是原因：将关键内容带到新聊天中。

面向开发者：API 中的相同中断

使用 stream: true 调用 API 时，同样的故障会表现为一个在没有 finish_reason 的情况下结束的 Server-Sent Events 连接。HTTP 状态为 200——发送响应头时一切正常——因此仅检查状态码无法检测到它；在负载较高时，还会出现 429 和 529 overloaded_error。三个做法可以让它变得可处理：(1) 将没有 finish_reason 就结束的流视为可重试，而不是完整响应；(2) 对 429、500 和 529 使用带 jitter 的指数退避重试；(3) 如果中间有代理，检查其空闲超时并禁用响应缓冲——缓冲代理会将正常工作的流变成长时间阻塞。为缩小范围，先在没有代理的情况下传输：

stream-test.sh

# Transmitir directamente, sin proxy por medio, y ver dónde se detiene.
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":"cuenta despacio del 1 al 20"}]}'

如果你通过 Kunavo 调用

Kunavo 是一个 AI API 网关，流式传输中断在这里是预期的运行状态，而不是异常。当某个模型配置了多个来源渠道且第一次尝试失败时，请求会在同一次调用中通过其他渠道重试，因此上游的暂时性问题会变成稍慢一些的成功，而不是错误。失败的请求从不计费。由于 GPT 和 Claude 可以使用同一个密钥访问，避开过载模型的方法是更改模型名称，而不是更改集成。流式传输场景的重试和退避模式详见 LLM API 流式传输错误.

常见问题

“消息流错误”是我的问题吗？

几乎从来不是。该消息表示传输响应的连接在完成前中断。不是您输入的内容导致了它。原因可能是 OpenAI 侧负载、网络不稳定、浏览器扩展或会话过期，也可能是线程增长到足够长，导致响应超时。

如果重新生成无法解决，该怎么办？

先查看 status.openai.com——发生故障期间，本地操作都没有帮助。如果没有故障，请在另一个网络中打开隐私窗口：这一个测试会同时移除扩展、缓存和您通常使用的连接。如果在那里正常，就逐项恢复这些因素，直到问题再次出现。如果所有地方都失败，并且只发生在某个长对话中，请将关键内容带到新聊天中。

其他 AI 也会发生这种情况吗？

这种措辞来自 ChatGPT，但任何以流式方式传送响应的助手都可能以同样方式中断。Claude 会显示无法生成完整响应的消息；直接调用 API 时，则表现为以没有 finish_reason 的 SSE 流结束，或在负载较高时出现 529 overloaded_error。

为什么长对话中更容易发生？

每一轮都会重新发送完整线程，因此长对话意味着在单个开放连接上持续更长时间的生成。连接保持开放的时间越长，代理超时、网络跳转或上游故障导致连接中断的机会就越多。带着重要内容的摘要开始新聊天，通常比任何浏览器设置调整都更有效。

ChatGPT 中的“消息流错误”——原因及解决方法

错误