Schnellstart Preise

Start → Hilfe

socket hang up mitten in einer gestreamten Antwort

Die TCP-Verbindung wurde geschlossen, bevor der Stream fertig war. Nichts in den Daten verrät, wer sie geschlossen hat, also ist die entscheidende Frage, ob je ein finish_reason ankam – ohne ihn behandeln Sie die Antwort als unvollständig und cachen sie nicht.

Was Sie sehen

Warum das passiert

Lange Streams durchqueren mehr Infrastruktur als kurze Anfragen: Ihr Netz, jeden Proxy, den Edge des Anbieters und den Modellhost. Ein Leerlauf-Timeout irgendwo in dieser Kette schließt die Verbindung, und der Client meldet einen Reset statt eines HTTP-Fehlers, weil die HTTP-Antwort schon mit 200 begonnen hat.

Mobilfunknetze und ein Laptop im Ruhezustand erzeugen dasselbe Bild. Ebenso ein Load Balancer mit kürzerem Leerlauf-Timeout als die Denkzeit des Modells – deshalb trifft es Reasoning-Modelle öfter als schnelle.

Ein Stream, der mit ordentlichem finish_reason endet und danach einen Fehler meldet, ist etwas anderes: Die Antwort ist vollständig, nur der Abbau ist gescheitert. Diese können Sie gefahrlos verwenden.

So beheben Sie es

  1. finish_reason als Abschlusssignal erfassenBehandeln Sie „der Stream ist zu Ende“ nicht als Erfolg. Markieren Sie eine Antwort erst als vollständig, wenn ein finish_reason ankam; sonst wiederholen oder als abgeschnitten melden.
  2. Die Anfrage wiederholen, nicht den StreamEine gestreamte Completion hat keinen Wiederaufsetzpunkt. Wiederholen Sie von vorn, am besten mit niedrigerem max_tokens, damit der nächste Versuch schneller fertig wird.
  3. Timeouts von Client und Proxy gemeinsam erhöhenNur den Client-Timeout zu erhöhen bringt nichts, wenn ein vorgeschalteter Proxy zuerst schließt. Beide müssen über der langsamsten erwarteten Antwort liegen.
Ein Stream, der unterwegs stirbt, wird für die bereits erzeugten Tokens trotzdem abgerechnet – die Arbeit ist geschehen. Ihr APICLAN-Nutzungslog zeigt genau, wie viele es waren, und so unterscheiden Sie eine halb fertige Antwort von einer, die nie begonnen hat.

Verwandte Themen

Unexpected token '<' beim Aufruf einer OpenAI-kompatiblen API401 invalid API key – wenn der Schlüssel richtig aussieht und trotzdem scheitert

Zuletzt geprüft am 2026-10-01. Geschrieben aus Problemen, die auf einem laufenden OpenAI-kompatiblen Gateway diagnostiziert wurden – nicht von anderen Seiten zusammengetragen.