当向浏览器流式传送 ChatGPT 答案的连接在答案完成前断开时，就会出现“Streaming interrupted. Waiting for the complete message”。这几乎从来不是您输入内容导致的：常见原因是 OpenAI 侧负载、连接不稳定、浏览器扩展，或线程变得过长。重新生成可以解决大多数情况；如果不能，只需检查一次状态，就能判断问题是否确实在您这边。
错误
Streaming interrupted. Waiting for the complete message...
(related wording for the same failure: "Error in message stream",
"Hmm...something seems to have gone wrong." The symptom is the same —
the answer stops partway and never completes.)原因和解决方法一览
| 原因 | 解决方法 |
|---|---|
| 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 directly, no proxy in the path, and watch where it stops.
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":"count slowly from 1 to 20"}]}'如果你通过 Kunavo 调用
Kunavo 是一个 AI API 网关，中断的流式传输是它专门设计来吸收的情况，而不是例外。当配置了多个上游通道且第一次尝试失败时，请求会在同一次调用中重试另一个通道，因此短暂的上游问题表现为稍慢一些但最终成功，而不是错误。失败的请求绝不会计费。由于 GPT 和 Claude 可以通过同一个密钥访问，过载的模型可以通过更换模型名称来绕开，无需修改集成。 流式传输情况下的重试与退避模式详见 LLM API 流式传输错误.
常见问题
“流式传输中断，正在等待完整消息”是我的问题吗？
几乎从来不是。这条消息表示承载回答的连接在回答完成前被切断。你输入的内容不会导致这种情况。原因可能是 OpenAI 端负载过高、网络不稳定、浏览器扩展或过期会话，也可能是线程过长导致响应超时。
如果重新生成仍无法修复怎么办？
先检查 status.openai.com——发生服务事件期间，本地操作都无济于事。如果没有服务事件，请在不同网络下打开隐私窗口：这项单独测试会同时排除扩展、缓存和你平时使用的连接。如果在那里正常，再逐项恢复，直到问题再次出现。如果在任何地方都失败，并且只发生在一个很长的对话中，请将要点转移到新聊天中。
其他 AI 聊天也会发生这种情况吗？
这种措辞来自 ChatGPT，但任何以流式方式传输回答的助手都可能以相同方式中断。Claude 会显示无法完成响应的消息；在直接 API 调用中，它表现为 Server-Sent Events 流在没有 finish_reason 的情况下结束，或在负载过高时返回 529 overloaded_error。
为什么长对话中错误出现得更频繁？
每一轮都会重新发送整个线程，因此长对话意味着在同一连接上进行更长时间的生成。连接保持打开的时间越长，代理超时、网络切换或上游短暂故障导致中断的机会就越多。带着重要内容的摘要开启新聊天，通常比调整任何浏览器设置都更有效。
流式传输中断时会收费吗？
ChatGPT 订阅不按消息收费，因此除了时间外没有损失。在 API 中，计费依据是提供商实际生成的令牌，因此提前结束的流式传输费用低于完整流式传输——而在 Kunavo 中，彻底失败的请求完全不计费。