當 ChatGPT 將答案串流至瀏覽器的連線在答案完成前中斷時，就會顯示「串流中斷，正在等待完整訊息」。這幾乎從來不是你輸入內容造成的：常見原因是 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 時，這項故障會以 Server-Sent Events 連線結束的形式出現，且沒有 finish_reason。HTTP 狀態為 200——標頭傳送時連線仍正常——因此只檢查狀態碼無法捕捉這項問題；在負載過高時，你也會看到 429 與 529 overloaded_error。三件事可讓系統承受這種情況：(1) 將沒有 finish_reason 就結束的串流視為可重試，而不是已完成的答案；(2) 對 429、500 與 529 使用指數退避加抖動重試；(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 則依提供者實際生成的 token 計費，因此提前中斷的串流成本低於完整串流——而在 Kunavo 上，完全失敗的請求完全不會計費。