Wenn Sie upstream connect error or disconnect/reset before headers in ChatGPT oder über die OpenAI API sehen, liegt das auf der Seite von OpenAI. Die Meldung stammt von Envoy, dem Proxy am OpenAI-Edge, und bedeutet, dass Envoy keine verwendbare Antwort vom Backend von OpenAI erhalten konnte. Auf der ChatGPT-Website wird dies oft als *Error Code 111* bezeichnet. Der Text nach reset reason: ist die eigentliche Diagnose, und before headers bedeutet, dass der Proxy aufgegeben hat, bevor auch nur ein einzelner Antwort-Header angekommen ist — hinter diesem 503 steckt also keine echte Antwort, sondern nur Envoys eigene. Sie können die Infrastruktur von OpenAI nicht reparieren, aber was Sie als Nächstes tun, hängt vom Reset-Grund und davon ab, ob Sie den Fehler im Browser oder per Code erhalten.
Welchen Weg verfolgen Sie:
- ChatGPT web/app: prüfe status.openai.com, dann lade die Seite neu oder starte eine neue Sitzung.
- OpenAI API in code: lies den Reset-Grund, erfasse die Request ID und wende dann eine Retry-Policy an.
Was der Fehler eigentlich bedeutet
Envoy sitzt zwischen Ihnen und dem Backend von OpenAI. Wenn Ihre Anfrage eintrifft, baut Envoy eine Verbindung zum Backend auf, leitet die Anfrage weiter und wartet auf die Response-Header. Wenn diese Verbindung fehlschlägt, zurückgesetzt wird, eine Zeitüberschreitung auftritt oder ein Kapazitätslimit erreicht wird, bevor irgendwelche Header zurückkommen, gibt Envoy diese Meldung mit einem HTTP 503 (manchmal 502) zurück. Sie erscheint auf Ausfallbildschirmen von ChatGPT, in Stacktraces von openai.InternalServerError und in Agent-Logs.
Die Formulierung variiert: Die Formulierung retried and the latest reset reason bedeutet, dass Envoy bereits erneut versucht hat und dies der Fehler des letzten Versuchs war. So oder so meldet der Proxy von OpenAI, dass sein eigenes Backend nicht geantwortet hat — kein Problem mit Ihrem Prompt oder Ihrem Request-Body.
Entschlüsseln Sie den Reset-Grund
Der Zurücksetzungsgrund sagt Ihnen, worauf der Proxy von OpenAI gestoßen ist, und damit auch, ob sich ein erneuter Versuch lohnt.
| Zurücksetzungsgrund | Was OpenAIs Proxy ausgelöst hat | Was Sie tun können |
|---|---|---|
connection timeout | Backend zu langsam, um die Verbindung rechtzeitig anzunehmen | Erneut mit Backoff versuchen; Status prüfen |
overflow | Eine Kapazitäts- oder Ratenbegrenzung wurde erreicht (Backend überlastet) | Parallelität reduzieren, zurückoffen, dann erneut versuchen |
connection failure / remote connection failure | Backend nicht erreichbar oder hat die Verbindung verweigert | Erneut versuchen; falls anhaltend, Status prüfen und melden |
connection termination / connection reset | Backend hat die Verbindung mitten in der Anfrage geschlossen | Erneut versuchen; stimmt meist mit einem Vorfall überein |
protocol error | Ein Protokollproblem auf OpenAIs Seite | Erneut versuchen; melden Sie es mit Ihrer Request ID, falls es bestehen bleibt |
overflow und connection timeout sind die beiden, die in OpenAI-Community-Berichten am häufigsten auftauchen, was zu einem Backend passt, das bei stoßartiger Last an seine Kapazitätsgrenzen stößt. Keines davon lässt sich durch etwas auf Ihrem Gerät beheben — die nützlichen Maßnahmen sind Statusprüfungen, Backoff und Failover.
Auf der ChatGPT-Website oder in der App (Fehlercode 111)
Überprüfen Sie zuerst status.openai.com. Wenn ein Vorfall gemeldet ist, ist Abwarten die wichtigste Lösung, auch wenn ein anhaltender konto-spezifischer Fehler dem Support gemeldet werden sollte. Wenn der Status grün ist, 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 aufrechterhalten. Das Wechseln des Netzwerks oder das Deaktivieren eines VPNs oder eines Unternehmens-Proxys hilft nur, wenn genau diese Ebene die Verbindung zurücksetzt; versuchen Sie es also, bevor Sie annehmen, dass es an OpenAI liegt.
Von der OpenAI API im Code
Hier ist der Fehler intermittierend und lastabhängig. Ein Entwickler im openai-python-Issue-Tracker berichtete, dass bei Hunderten von Anfragen pro Stunde ungefähr 5 % der Aufrufe mit openai.InternalServerError: upstream connect error or disconnect/reset before headers fehlschlugen — die anderen 95 % waren erfolgreich. Eine teilweise Ausfallrate wie diese deutet auf eine Backend-Sättigung hin, und batchlastige Jobs (Massen-Embeddings, große Dokumenten-Ingestion) treffen häufiger darauf, weil sie die Parallelität erhöhen. Die Lösung ist in der Regel eher eine Retry-Policy als eine Änderung des Payloads, obwohl die Steuerung der Parallelität und das Queuing von Batch-Jobs bei hoher Last ebenso wichtig sind.
Bevor Sie eskalieren, erfassen Sie genug, um zu belegen, dass es auf der Anbieterseite liegt: den Zeitstempel, den Endpoint und das Modell, den HTTP-Status und den Body, die x-request-id, Ihre SDK-Version, die Anzahl der laufenden Anfragen und ob die Fehler mit einem veröffentlichten Incident zusammenfallen. Wenden Sie dann eine Retry-Policy an, die in der Produktion standhält:
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)
# Verbindungsabbrüche und 5xx erneut versuchen (inkl. dieses 503); 4xx niemals blind erneut versuchen
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 vorübergehende Fehler bereits von selbst (max_retries, Standard 2), also setzen Sie das bewusst — zum Beispiel OpenAI(max_retries=0) — bevor Sie Aufrufe wrappen, sonst stapeln sich Ihre Ebene und die des SDK. Begrenzen Sie die Gesamtzahl der Versuche (3–5) und die gesamte Parallelität, damit Wiederholungen den Burst nicht verstärken, der zum overflow geführt hat. Behandeln Sie 429 gemäß Retry-After; wiederholen Sie 408/409 nur, wenn der Vorgang gefahrlos erneut ausgeführt werden kann. Seien Sie vorsichtig bei nicht-idempotenten oder Streaming-Aufrufen — ein blindes Retry kann Arbeit duplizieren oder einen halb konsumierten Stream erneut abspielen.
Wie es auf der Client-Seite aussieht
Oft sieht man den 503-Body von Envoy nicht einmal — die Verbindung bricht zuerst ab. Ein curl -v gegen einen toten Endpunkt gibt nach Request completely sent off curl: (52) Empty reply from server zurück: Die Anfrage wurde gesendet, es kam nichts zurück. Envoys eigene Version des Fehlers ist ein 503, der den Text upstream connect error... als Body enthält. Die öffentlichen Berichte stimmen überein: Im OpenAI-Subreddit postete ein Nutzer die exakte Zeichenkette retried and the latest reset reason: connection timeout zusammen mit "Network connection lost," und der openai-python-Tracker führt dieselbe Meldung als InternalServerError bei hohem Anfragevolumen.
Wann man es umgeht
Da der ausfallende Hop zwischen OpenAIs Gateway und dessen Backend liegt, ist Wiederholen und Zurückweichen alles, was du gegen einen einzelnen Endpunkt tun kannst. Der andere Hebel ist Redundanz: leite über eine Ebene weiter, die bei einem Timeout oder Overflow eines Upstreams auf ein anderes Backend ausweicht. Multi-Provider-Gateways wie OpenRouter und AIReiter stehen vor mehreren Modellanbietern und leiten um einen langsamen herum, auf demselben Multi-Provider-Routing-Modell, auf dem OpenRouter basiert, sodass ein einzelner langsamer Upstream eher zu einer Umleitung als zu einem sichtbaren 503 werden kann. Der Kompromiss ist real — ein zusätzlicher Hop, eine Abhängigkeit von der Verfügbarkeit des Routers selbst sowie Unterschiede bei Preisgestaltung, Datenverarbeitung und Beobachtbarkeit, die man abwägen muss — aber er verringert die Anfälligkeit gegenüber der Instabilität eines einzelnen Anbieters.
FAQ
Was ist der ChatGPT-Fehlercode 111?
Einige ChatGPT-Nutzer berichten, dass sie diese Nachricht zusammen mit der Bezeichnung "Error Code 111" sehen. Das bedeutet, dass OpenAIs Proxy keine Antwort von seinem Backend erhalten konnte — ein serverseitiges Problem. Überprüfen Sie status.openai.com und laden Sie die Seite neu.
Warum bekomme ich es nur unter Last oder zufällig?
Lastabhängige Ausfälle bedeuten normalerweise overflow (ein Kapazitäts- oder Ratenlimit) oder eine Sättigung des Backends, die die Verbindungszeiten über das Timeout hinausdrückt. Beides tritt nur auf, wenn die Parallelität steigt, weshalb derselbe Code die meiste Zeit funktioniert.
Verursacht ein VPN oder eine Firewall dies?
Nur wenn diese Schicht die Verbindung zwischen Ihnen und OpenAI zurücksetzt. Es lohnt sich, dies durch Wechseln des Netzwerks auszuschließen, aber es wird keinen echten Ausfall bei OpenAI oder ein 503 auf API-Seite beheben.
Ist das dasselbe wie ein 429-Rate-Limit-Fehler?
Nein. Ein 429 ist eine explizite Rate-Limit-Antwort, die Sie erhalten haben. Dieses 503 bedeutet, dass überhaupt keine verwertbare Antwort zurückkam. Beachten Sie Retry-After bei einem 429; legen Sie bei dem 503 eine Pause ein und versuchen Sie es erneut.
Was bedeutet „erneut versucht und der neueste Reset-Grund“?
Envoy hat die Anfrage bereits erneut versucht, und deshalb ist der letzte Versuch fehlgeschlagen. Dies deutet auf ein anhaltendes Backend-Problem auf Seiten von OpenAI hin und nicht auf eine einmalige Störung.