Stream Closed Before Completed
Vier Ursachen, eine Hop-für-Hop-Methode
Eine Streaming-Antwort bricht mittendrin mit der Fehlermeldung „stream closed before completed“ ab. Es gibt vier häufige Ursachen, die ihrer Art nach völlig verschieden sind. Nur eine Prüfung Hop für Hop führt zur richtigen.
Aktualisiert 2026-08-27
Vier wichtige Fakten
Vier häufige Ursachen
Ein Rate-Limit-Frame des Anbieters, nicht aufeinander abgestimmte Timeouts in der Kette, ein Verbindungsabbruch des Clients oder eine Rewrite-Schicht, die das abschließende Event verschluckt: Sie sehen ähnlich aus, haben aber völlig unterschiedliche Ursachen.
Der Kern der Eingrenzungsmethode
Der Weg vom Client zum Modelldienst führt meist über mehrere Hops (Client → Gateway → Load Balancer → Anbieter). Sie müssen jeden Hop prüfen, um herauszufinden, wo der Abbruch tatsächlich passiert ist.
Ob das abschließende Event ankommt
Viele Streaming-Protokolle kennzeichnen ein normales Ende durch ein abschließendes Event (etwa [DONE]). Bricht der Stream ab, bevor es erscheint, wurde er abgeschnitten und nicht normal beendet.
Die am häufigsten übersehene Ursache
Client, Gateway und Load Balancer setzen meist jeweils ein eigenes Timeout. Ist das Timeout auch nur eines Hops kürzer als die tatsächliche Generierungsdauer des Modells, trennt dieser Hop den Stream zwangsweise.
Was die vier Ursachen im Einzelnen sind
Erstens ein Rate-Limit-Frame des Anbieters: Der Modelldienst stößt mitten in der Generierung auf ein Rate Limit und fügt ein Unterbrechungssignal ein, das die Generierung vorzeitig beendet. Der Client sieht nur, dass der Stream vor dem Ende abbricht. Zweitens nicht abgestimmte Timeouts: Die Anfrage durchläuft mehrere Hops (Client, Proxy, Gateway, Load Balancer). Ist das konfigurierte Timeout auch nur eines Hops kürzer als die tatsächliche Generierungsdauer des Modells, trennt dieser Hop die Verbindung aktiv, obwohl das Modell normal weiter generiert. Drittens der Verbindungsabbruch des Clients (client gone): Der Nutzer hat die Seite geschlossen oder die Anfrage zwischendurch abgebrochen, oder der Container bzw. Prozess des Clients wurde freigegeben. Ein solcher Abbruch hinterlässt in den Server-Logs meist einen Eintrag wie „peer closed connection“ und weist in die entgegengesetzte Richtung wie die ersten beiden Ursachen. Viertens eine Rewrite-Schicht, die das abschließende Event verschluckt: Manche Reverse-Proxys, CDNs oder Rewrite-Middleware verarbeiten den Body der Streaming-Antwort erneut. Enthält ihre Implementierung einen Fehler, leiten sie den eigentlichen Inhalt korrekt weiter, verlieren aber das abschließende Event, das „Generierung normal beendet“ signalisiert (etwa [DONE] bei SSE). Der Client hält die Verbindung dann für abnormal abgebrochen, obwohl das Modell die Generierung einwandfrei abgeschlossen hat.
Warum sich diese Eingrenzungsmethode lohnt
Von den vier Ursachen werden die ersten beiden (Rate-Limit-Frame, nicht abgestimmte Timeouts) am häufigsten fälschlich als „unser Netzwerk ist instabil“ diagnostiziert. Der dritten (Verbindungsabbruch des Clients) wird serverseitig oft zu Unrecht mit „das Modell ist unzuverlässig“ begegnet. Die vierte (Rewrite-Schicht verschluckt das abschließende Event) ist die tückischste: Der beim Client eingehende Inhalt wirkt vollständig, es fehlt nur das eine verräterische Schlusssignal. Deshalb wird sie leicht als „zufälliger Bug“ abgetan statt als systematisches Problem erkannt.
Zeitverlauf
Streaming-Antworten (SSE und ähnliche Protokolle) und ihr Mechanismus des abschließenden Events sind ein etabliertes Standarddesign. Alle vier Abbruchursachen gibt es, seit Streaming verbreitet ist.
Agentische Workflows erhöhen die Zahl lang laufender Streaming-Generierungen. Dadurch treten schlecht eingestellte Timeouts an beliebiger Stelle der Kette eher zutage.
Die tückischste Ursache, eine Rewrite-Schicht, die das abschließende Event verschluckt, tritt häufiger auf, je komplexer Reverse-Proxy- und CDN-Middleware werden.
Bestätigt vs. verbreitete Fehldeutung
Bestätigt
Die Meldung „stream closed before completed“ taucht in öffentlichen Entwicklerdiskussionen durchgängig auf. Alle vier Ursachen (Rate-Limit-Frame, nicht abgestimmte Timeouts, Verbindungsabbruch des Clients, Rewrite-Schicht verschluckt das Event) sind jeweils für sich dokumentiert und müssen getrennt diagnostiziert werden.
Verbreitete Fehldeutung
Bei einem Stream-Abbruch lautet die erste Vermutung vieler: „Das Modell ist unzuverlässig“ oder „der Dienst des Anbieters ist defekt“. In der Praxis machen jedoch nicht abgestimmte Timeouts und Fehler in Rewrite-Schichten, beides Konfigurations- bzw. Implementierungsprobleme auf Client- oder Middleware-Seite, einen erheblichen Anteil der Fälle aus.
So unterscheiden Sie die vier Ursachen
Abbruch auf Serverseite (Rate-Limit-Frame / Timeout)
Die Server-Logs zeigen, dass diese Generierung per Rate Limit begrenzt wurde oder dass das Timeout eines Hops den Abbruch ausgelöst hat. Typisch ist, dass dieselbe Anfrage zu einem anderen Zeitpunkt oder bei geringerer Parallelität oft problemlos durchläuft.
Problem auf Client-Seite (Verbindungsabbruch / Rewrite-Schicht verschluckt das Event)
Die Server-Logs zeigen, dass die Generierung tatsächlich normal beendet wurde. Das Problem ist, dass der Client die Verbindung zu früh trennt oder dass eine dazwischenliegende Rewrite-Schicht das abschließende Event nicht weiterleitet. Dann müssen Sie die Konfiguration von Client bzw. Proxy prüfen, nicht den Modelldienst.
Die Hop-für-Hop-Eingrenzungsmethode
Schritt 1: Prüfen Sie die Server-Logs. Wurde diese Generierung tatsächlich bis zum Ende ausgeführt, und wurde sie per Rate Limit begrenzt? Wenn die Server-Aufzeichnungen ein normales Ende zeigen, liegt das Problem sehr wahrscheinlich auf einem Hop zwischen Client und Server. Schritt 2: Prüfen Sie die Timeout-Einstellungen Hop für Hop (Client-Timeout, CDN-/Gateway-Timeout, Load-Balancer-Timeout) und finden Sie heraus, welches kürzer ist als die tatsächliche Generierungsdauer des Modells. Schritt 3: Vermuten Sie eine Rewrite-Schicht, die das Event verschluckt, vergleichen Sie direkt den vom Server gesendeten Roh-Stream mit dem, was der Client tatsächlich empfangen hat, und prüfen Sie, ob das abschließende Event unterwegs verloren gegangen ist. Schritt 4: Trennt der Client die Verbindung absichtlich (z. B. weil der Nutzer manuell abgebrochen hat), ist das gar kein Fehler. Sie müssen diesen Abbruchfall lediglich in Ihrer Anwendungslogik korrekt behandeln, statt ihn als Systemausfall zu deuten.
Was Sie bei QCode tun können
Die Edge-Knoten von QCode gleichen die Timeouts für Streaming-Antworten ab. So wird seltener eine lange Generierung fälschlich abgebrochen, weil der Timeout auf einem Hop nicht passt. Wenn Ihr eigener Proxy oder Ihre Rewrite-Middleware ein ähnliches Problem hat, können Sie übergangsweise auch über einen QCode-Endpunkt routen, während Sie die Ursache eingrenzen.
FAQ
Woran erkenne ich, ob ein Stream-Abbruch auf meiner Seite liegt?
Prüfen Sie zuerst die Server-Logs, sofern Sie darauf zugreifen können: Zeigen sie, dass die Generierung normal abgeschlossen wurde, liegt das Problem sehr wahrscheinlich auf einem Hop zwischen Client und Server (Timeout-Einstellungen, eine Rewrite-Schicht usw.) – und lässt sich von Ihnen diagnostizieren und beheben.
Warum funktioniert dieselbe Anfrage manchmal und bricht manchmal ab?
Der häufigste Grund ist ein Timeout-Mismatch: Die Generierungsdauer schwankt naturgemäß, und sobald sie zufällig den kürzesten Timeout-Schwellenwert irgendwo in der Kette überschreitet, wird genau diese Anfrage abgebrochen, während schnellere Anfragen problemlos durchlaufen.
Gilt es als Fehler, wenn der Client die Verbindung trennt?
Streng genommen nein – es ist normales Nutzerverhalten (eine Anfrage abbrechen, die Seite schließen) oder eine Änderung der Client-Umgebung (der Prozess wird beendet); es muss lediglich in Ihrer Anwendungslogik korrekt erkannt und behandelt werden, statt es als Systemfehler zu verfolgen.
Wie diagnostiziere ich am schnellsten, dass eine Rewrite-Schicht das abschließende Event verschluckt?
Erfassen Sie den Datenverkehr oder ergänzen Sie Logging, das direkt vergleicht, was der Server tatsächlich gestreamt hat und was der Client am Ende empfangen hat – wenn der Server das abschließende Event gesendet hat, der Client es aber nie erhalten hat, liegt das Problem in einer dazwischenliegenden Rewrite-/Weiterleitungsschicht.
Was sollte ich zuerst prüfen, wenn dieser Fehler auftritt?
Prüfen Sie zuerst die Server-Logs auf Rate Limits oder Fehler; ist dort nichts zu finden, kontrollieren Sie die Timeout-Einstellungen von Client, Gateway und Load Balancer – mit diesen beiden Schritten schließen Sie drei der vier Ursachen aus.
Ist das dasselbe wie 429/529?
Nein. 429/529 bedeuten, dass die Anfrage abgelehnt wird, bevor die Generierung überhaupt beginnt; „stream closed before completed“ bedeutet, dass die Generierung bereits begonnen hatte und der Stream schon offen war, dann aber vor dem Abschluss abgebrochen wurde – beides geschieht in völlig verschiedenen Phasen.
Quellen
Die vier Ursachen wurden aus öffentlichen Entwicklerdiskussionen, dem Standardverhalten von Streaming-Protokollen wie SSE und der allgemeinen Betriebspraxis der Hop-für-Hop-Timeout-Eingrenzung zusammengestellt; diese Seite trifft keine Aussagen über die private Implementierung eines einzelnen Anbieters. Stand: 2026-08-27.
Stream-Abbrüche sollten die Auslieferung nicht ausbremsen
Die Edge-Knoten von QCode gleichen die Timeouts für Streaming-Antworten ab und reduzieren so Abbrüche durch nicht aufeinander abgestimmte Hops bei langen Generierungen.
Weiterführende Artikel
Context Length Exceeded: der vollständige Leitfaden
Ein weiterer häufig falsch diagnostizierter Fehler – ein nützlicher Vergleich.
Der vollständige Leitfaden zur Abfrage der Nutzung Ihres API-Keys
So werten Sie Ihren eigenen Aufrufverlauf und Auffälligkeiten systematisch aus.
Claude 529 vs. 429 vs. Weekly Limit
Eine weitere Gruppe leicht zu verwechselnder Fehler – sauber voneinander abgegrenzt.
Diese Seite bietet eine allgemeine, anbieterübergreifende technische Erläuterung und trifft keine Aussagen über die private Implementierung eines einzelnen Anbieters. Das tatsächliche Verhalten hängt vom konkreten Modell, Client und der von Ihnen genutzten Proxy-Kette ab.