當 ChatGPT 用來逐段傳送回覆的連線在回覆完整前中斷時，就會出現「訊息串流錯誤」。這幾乎從來不是您的輸入造成的：原因幾乎總是 OpenAI 端過載、連線不穩定、瀏覽器擴充功能，或聊天內容過長。重新產生回覆可以解決大多數情況 — 如果仍未解決，只要查看一次狀態頁面，就能知道問題是否真的出在您這端。
錯誤
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 或公司 Proxy、訊號微弱。串流會維持單一長連線，在一般頁面載入仍可通過的地方，串流可能中斷。 | 關閉 VPN 或 Proxy，並透過另一條連線重新嘗試（Wi-Fi ⇄ 行動網路）。 |
| 瀏覽器環境：干預頁面的擴充功能、過時的快取，或已過期的工作階段。 | 在無痕視窗中重新嘗試。如果在那裡可以運作，問題就在擴充功能或快取 — 停用擴充功能、清除網站資料，然後重新登入。 |
| 聊天內容過長或附件太大。每次操作都會再次傳送完整記錄，產生時間更長，也更容易中斷。 | 將重點內容移至新的聊天。將大型檔案分割，而不是整個附加。 |
前 90 秒應執行的三個步驟
重新產生回覆 → 重新載入頁面（在應用程式中完全結束後重新啟動）→ 登出再重新登入。一次性中斷的串流通常只需這三個步驟之一即可解決，而一次性中斷才是正常情況。相反地，如果每次都在相同位置中斷，這表示下方某個具體原因正在發生，而不是偶然事件。
先確認問題是否真的出在您這端
這是其他指南會跳過、但最能節省時間的一步。開啟 status.openai.com。如果上面顯示正在發生服務中斷，任何本機設定都無法提供幫助，等待是唯一的解決方法。如果沒有顯示任何問題，原因就在您這端，下一步可以進一步縮小範圍。在調整設定前先完成這項檢查，就不會在服務中斷期間花二十分鐘清除快取。
由外而內縮小本機原因範圍
依照以下順序進行，因為每個階段都會排除其上方的所有可能性：(1) 關閉 VPN 與 Proxy；(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) 如果位於 Proxy 後方，檢查其閒置逾時並關閉回應緩衝 — 會進行緩衝的 Proxy 會將可正常運作的串流變成長時間阻塞。為了縮小範圍，先不經 Proxy 進行串流：
# 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。
為什麼長時間的對話更容易發生這種情況？
每次操作都會再次傳送完整記錄，因此長時間的對話意味著要在單一開放連線上進行更長時間的產生。連線保持開啟的時間越長，Proxy 逾時、網路切換或上游暫時中斷將其切斷的機會就越多。使用重要內容摘要建立新的聊天，通常比調整任何瀏覽器設定更有效。