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

当 ChatGPT 用来逐段传输回答的连接在回答完成前中断时，就会出现“消息流错误”。这几乎从来不是您的输入导致的：原因通常是 OpenAI 端过载、连接不稳定、浏览器扩展或聊天过长。重新生成回答可以解决大多数情况；如果仍未解决，只需查看一次状态页面，就能判断问题是否确实出在您这边。

错误

ChatGPT 聊天中的显示

Fehler im Nachrichtenstrom

(Gleiche Störung, andere Formulierungen: „Streaming unterbrochen.
 Warte auf die vollständige Nachricht", „Hmm...da ist wohl etwas
 schiefgelaufen." Symptom ist immer dasselbe — die Antwort bleibt
 mitten im Satz stehen und wird nie fertig.)

原因和解决方法一览

原因	解决方法
OpenAI 端过载或服务故障。它会同时影响所有套餐，包括 Plus 和 Pro；如果错误每隔几分钟就重复出现，这是最可能的原因。	检查 status.openai.com。服务故障期间，您这边的任何设置都无法改变情况——等待才是解决办法。
连接不稳定：在 Wi-Fi 和移动网络、VPN 或公司代理之间切换，或信号较弱。流式传输会保持一条长连接，在普通页面访问尚能通过的情况下，这条连接仍可能中断。	关闭 VPN 或代理，并通过另一条线路重试（Wi-Fi ⇄ 移动网络）。
浏览器环境：某个干预页面的扩展、过期缓存或已失效的会话。	在隐私窗口中重试。如果在那里可以正常运行，问题就出在扩展或缓存——停用扩展、清除网站数据，然后重新登录。
聊天过长或附件过大。每次交互都会再次发送完整历史记录，生成耗时更长，也更容易中断。	将要点转移到新聊天中。将大文件拆分，而不是一次性完整附加。

前 90 秒应执行的三个操作

重新生成回答 → 重新加载页面（在应用中彻底退出并重新启动）→ 退出登录后重新登录。一次性中断的流通常通过这三个步骤之一即可解决，而一次性中断才是正常情况。但如果每次都在同一位置中断，这说明下面列出的某个具体原因可能存在，而不是偶然事件。

先确认问题是否真的出在你这边

这是其他指南会跳过、却最能节省时间的一步。打开 status.openai.com。如果那里显示正在发生的故障，本地设置无法解决问题，只能等待。如果没有显示故障，原因就在你这边，下一步会进一步缩小范围。在反复调整设置前先做这项检查，就不会在服务中断期间浪费二十分钟清除缓存。

从外到内排查本地原因

按此顺序进行，因为每一级都会排除上面的所有可能性：(1) 关闭 VPN 和代理；(2) 打开隐私窗口——一次性停用扩展并绕过缓存；(3) 更换浏览器或设备；(4) 切换网络。恢复正常的那一级就是原因。如果错误只出现在很长的聊天中，四项都不是原因——此时将核心要点转移到新聊天中。

开发者注意：API 中出现同样的中断

使用 stream: true 发起调用时，同一故障会表现为在出现 finish_reason 之前结束的 Server-Sent Events 连接。HTTP 状态为 200——因为发送标头时一切正常——因此仅检查状态码无法识别中断；高负载下还会出现 429 和 529 overloaded_error。要让系统应对这种情况，需要做到三点：(1) 将没有 finish_reason 就结束的流视为可重试，而不是完整响应；(2) 对 429、500 和 529 使用带抖动的指数退避重试；(3) 如果位于代理后面，检查代理的空闲超时并关闭响应缓冲——会缓冲响应的代理会把正常工作的流变成长时间阻塞。排查时先不使用代理进行流式请求：

stream-test.sh

# Direkt streamen, kein Proxy dazwischen, und beobachten, wo es abbricht.
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":"Zähle langsam von 1 bis 20"}]}'

如果你通过 Kunavo 调用

Kunavo 是 AI API 网关，会将中断的流视为运行状态，而不是异常。如果某个模型配置了多个上游通道，第一次尝试失败后，同一请求会在同一次调用中通过另一个通道重试——这样，上游的暂时性故障就会变成稍慢但成功的响应，而不是错误。失败的请求绝不会计费。由于 GPT 和 Claude 可通过一个密钥访问，模型过载时只需换用另一个模型名称，无需进行第二次集成。流式场景的重试和退避模式完整写在 LLM API 流式传输错误.

常见问题

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

实际上几乎从来不是。此消息表示承载响应的连接在响应完成前中断了。你的输入不会导致这一问题。原因可能是 OpenAI 方面负载过高、网络连接不稳定、浏览器扩展或会话过期，也可能是聊天过长，导致响应超时。

重新生成无效时该怎么办？

先检查 status.openai.com——发生故障时，本地操作都没有帮助。如果没有故障，请通过其他网络在隐私窗口中打开页面：这一次测试会同时绕过扩展、缓存和你惯用的网络连接。如果在那里正常，再逐一重新启用它们，直到问题再次出现。如果所有地方都失败，而且只发生在一个很长的聊天中，将核心要点转移到新聊天中。

其他 AI 聊天也会出现这种情况吗？

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

为什么长对话中更常发生？

每次请求都会重新发送完整的对话历史，因此长对话意味着在单个开放连接上进行更长时间的生成。连接保持开放的时间越长，代理超时、网络切换或上游短暂故障将其切断的机会就越多。带有要点摘要的新聊天通常比任何浏览器设置都更有效。

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

错误