AIREITERDie Meldung upstream connect error or disconnect/reset before headers in ChatGPT oder bei Aufrufen der OpenAI API hat ihre Ursache auf Seiten von OpenAI. Sie stammt von Envoy, dem Proxy am Netzwerkrand von OpenAI: Er konnte vom OpenAI-Backend keine verwertbare Antwort erhalten. Auf der ChatGPT-Website erscheint das häufig als Error Code 111. Entscheidend ist der Text hinter reset reason:. before headers bedeutet dabei, dass der Proxy aufgegeben hat, noch bevor auch nur ein Response-Header eingetroffen ist. Hinter dem 503 steckt also keine eigentliche Backend-Antwort, sondern lediglich Envoys eigene Fehlermeldung. OpenAIs Infrastruktur können Sie nicht selbst reparieren – das weitere Vorgehen hängt aber vom Reset-Grund und davon ab, ob der Fehler im Browser oder im Code auftritt.
Welcher Fall trifft auf Sie zu:
- ChatGPT im Web oder in der App: Prüfen Sie status.openai.com und laden Sie anschließend neu oder starten Sie eine neue Sitzung.
- OpenAI API im Code: Lesen Sie den Reset-Grund aus, speichern Sie die Request-ID und setzen Sie eine Retry-Strategie um.
Was diese Meldung konkret aussagt
Envoy sitzt zwischen Ihrem Client und dem OpenAI-Backend. Geht eine Anfrage ein, baut der Proxy eine Verbindung zum Backend auf, leitet die Anfrage weiter und wartet auf die Response-Header. Scheitert dieser Verbindungsaufbau, wird die Verbindung zurückgesetzt, läuft sie in ein Timeout oder greift vor dem Eintreffen von Headern ein Kapazitätslimit, liefert Envoy die Meldung mit HTTP 503 zurück – gelegentlich auch mit 502. Sie taucht auf ChatGPT-Ausfallseiten, in Stacktraces mit openai.InternalServerError und in Agent-Logs auf.
Die genaue Formulierung kann variieren. Steht dort retried and the latest reset reason, hat Envoy die Anfrage bereits erneut versucht; genannt wird dann der Fehler des letzten Versuchs. In jedem Fall meldet der OpenAI-Proxy, dass das eigene Backend nicht geantwortet hat. Weder Ihr Prompt noch der Request-Body sind die Ursache.
Reset-Gründe richtig einordnen
Der Reset-Grund zeigt, woran der OpenAI-Proxy gescheitert ist – und damit auch, ob sich ein erneuter Versuch lohnt.
| reset reason | Was beim OpenAI-Proxy passiert ist | Was Sie tun können |
|---|---|---|
connection timeout | Das Backend hat die Verbindung nicht rechtzeitig angenommen | Mit Backoff erneut versuchen; Status prüfen |
overflow | Ein Kapazitäts- oder Ratenlimit wurde erreicht; das Backend ist überlastet | Parallelität senken, Backoff anwenden, dann erneut versuchen |
connection failure / remote connection failure | Das Backend war nicht erreichbar oder hat die Verbindung abgelehnt | Erneut versuchen; bei anhaltendem Fehler Status prüfen und melden |
connection termination / connection reset | Das Backend hat die Verbindung während der Anfrage geschlossen | Erneut versuchen; fällt meist mit einem Incident zusammen |
protocol error | Ein Protokollproblem auf Seiten von OpenAI | Erneut versuchen; bei anhaltendem Fehler mit Request-ID melden |
overflow und connection timeout werden in Berichten aus der OpenAI-Community besonders häufig genannt. Das passt zu einem Backend, das bei Lastspitzen an seine Kapazitätsgrenzen stößt. Keiner dieser Fälle lässt sich durch Änderungen am eigenen Rechner beheben. Sinnvoll sind Status-Checks, Backoff und Failover.
ChatGPT im Browser oder in der App: Error Code 111
Schauen Sie zuerst auf status.openai.com. Bei einem gemeldeten Incident hilft vor allem Abwarten. Tritt der Fehler dauerhaft und nur für Ihr Konto auf, sollten Sie den Support kontaktieren. Ist der Status grün, laden Sie die Seite neu, öffnen Sie einen neuen Tab oder melden Sie sich ab und wieder an – eine veraltete Sitzung kann eine tote Verbindung festhalten. Ein Netzwerkwechsel oder das Deaktivieren eines VPNs beziehungsweise Unternehmens-Proxys hilft nur, wenn genau diese Schicht die Verbindung zurücksetzt. Testen Sie das, bevor Sie automatisch von einem OpenAI-Problem ausgehen.
OpenAI API: Umgang im Code
Bei der API tritt der Fehler typischerweise sporadisch und lastabhängig auf. Ein Entwickler berichtete im openai-python-Issue-Tracker, dass bei mehreren hundert Anfragen pro Stunde rund 5 % mit openai.InternalServerError: upstream connect error or disconnect/reset before headers fehlschlugen – die übrigen 95 % waren erfolgreich. Eine solche Teilfehlerrate deutet auf eine Backend-Sättigung hin. Besonders batchintensive Jobs wie Massen-Embeddings oder die Aufnahme großer Dokumentmengen stoßen häufiger darauf, weil sie die Parallelität erhöhen. Meist ist eine Retry-Strategie die Lösung, nicht eine Änderung des Payloads. Unter hoher Last sind jedoch auch begrenzte Parallelität und Warteschlangen für Bulk-Jobs genauso wichtig.
Bevor Sie den Fall eskalieren, sammeln Sie ausreichend Informationen, um die Provider-Seite als Ursache zu belegen: Zeitstempel, Endpoint und Modell, HTTP-Status und Response-Body, x-request-id, SDK-Version, Anzahl parallel laufender Requests sowie den Abgleich mit gemeldeten Incidents. Danach brauchen Sie eine produktionsfeste Retry-Strategie:
import random, time
from openai import OpenAI, APIStatusError, APIConnectionError
client = OpenAI()
def with_retry(fn, max_attempts=5, cap=30.0):
for attempt in range(max_attempts):
try:
return fn()
except (APIConnectionError, APIStatusError) as e:
status = getattr(e, "status_code", None)
# retry connection drops and 5xx (incl. this 503); never blindly retry 4xx
if isinstance(e, APIStatusError) and status and status < 500 and status != 429:
raise
if attempt == max_attempts - 1:
raise
retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
backoff = retry_after or min(cap, 0.5 * 2 ** attempt) * (0.5 + random.random())
time.sleep(backoff)Die OpenAI SDKs wiederholen temporäre Fehler bereits selbstständig (max_retries, standardmäßig 2). Legen Sie diese Einstellung daher bewusst fest, etwa mit OpenAI(max_retries=0), bevor Sie Calls zusätzlich wrappen. Andernfalls addieren sich die Retries Ihrer Schicht und die des SDKs. Begrenzen Sie die Gesamtzahl der Versuche auf 3–5 und ebenso die gesamte Parallelität, damit Retries nicht genau den Burst verstärken, der overflow ausgelöst hat. Bei 429 richten Sie sich nach Retry-After; 408/409 sollten Sie nur erneut versuchen, wenn der Vorgang sicher wiederholbar ist. Vorsicht bei nicht idempotenten oder Streaming-Calls: Ein unbedachter Retry kann Arbeit duplizieren oder einen teilweise konsumierten Stream erneut abspielen.
Wie sich der Fehler clientseitig zeigt
Oft sehen Sie den 503-Body von Envoy gar nicht, weil die Verbindung vorher abbricht. Ein curl -v gegen einen nicht erreichbaren Endpoint liefert nach Request completely sent off die Meldung curl: (52) Empty reply from server: Die Anfrage wurde versendet, zurück kam nichts. Envoys eigene Variante ist dagegen ein 503, dessen Body den Text upstream connect error... enthält. Das deckt sich mit öffentlichen Berichten: Im OpenAI-Subreddit postete ein Nutzer exakt die Zeichenfolge retried and the latest reset reason: connection timeout zusammen mit „Network connection lost“. Im openai-python-Tracker erscheint dieselbe Meldung bei hohem Anfragevolumen als InternalServerError.
Wann sich ein alternativer Routing-Weg lohnt
Da der fehlerhafte Hop zwischen OpenAIs Gateway und dem Backend liegt, bleiben bei einem einzelnen Endpoint nur Retries und Backoff. Der andere Ansatz heißt Redundanz: über eine Schicht routen, die bei Timeouts oder overflow eines Upstreams auf ein anderes Backend ausweicht. Multi-Provider-Gateways wie OpenRouter und AIReiter bündeln mehrere Modellanbieter und können einen langsamen Anbieter umgehen. Das entspricht dem Multi-Provider-Routing-Modell, auf dem OpenRouter aufbaut: Wird ein einzelner Upstream langsam, kann daraus ein Routing-Wechsel statt eines sichtbaren 503 werden. Der Kompromiss ist real: ein zusätzlicher Hop, Abhängigkeit von der Verfügbarkeit des Routers selbst sowie Unterschiede bei Preisen, Datenverarbeitung und Observability. Dafür sinkt die Abhängigkeit von der Stabilität eines einzelnen Providers.
FAQ
Was bedeutet ChatGPT Error Code 111?
Einige ChatGPT-Nutzer sehen diese Meldung zusammen mit der Bezeichnung „Error Code 111“. Sie bedeutet, dass der OpenAI-Proxy keine Antwort vom Backend erhalten hat – also ein serverseitiges Problem. Prüfen Sie status.openai.com und laden Sie die Seite neu.
Warum passiert das nur unter Last oder scheinbar zufällig?
Lastabhängige Fehler bedeuten meist overflow – ein Kapazitäts- oder Ratenlimit – oder ein gesättigtes Backend, bei dem der Verbindungsaufbau ins Timeout läuft. Beides tritt erst bei steigender Parallelität auf. Deshalb funktioniert derselbe Code die meiste Zeit problemlos.
Kann ein VPN oder eine Firewall die Ursache sein?
Nur wenn genau diese Schicht die Verbindung zwischen Ihnen und OpenAI zurücksetzt. Ein Netzwerkwechsel ist ein sinnvoller Ausschlusstest, behebt aber weder einen echten OpenAI-Ausfall noch einen API-seitigen 503.
Ist das dasselbe wie ein 429-Rate-Limit-Fehler?
Nein. Ein 429 ist eine explizite Rate-Limit-Antwort, die Sie erhalten haben. Dieser 503 bedeutet, dass überhaupt keine verwertbare Antwort zurückkam. Beachten Sie bei 429 Retry-After; bei 503 helfen Backoff und ein erneuter Versuch.
Was heißt „retried and the latest reset reason“?
Envoy hat die Anfrage bereits wiederholt, und der angegebene Grund erklärt das Scheitern des letzten Versuchs. Das weist auf ein anhaltendes Backend-Problem auf Seiten von OpenAI hin, nicht auf einen einmaligen kurzen Aussetzer.