Was ist Fehler 502 (Bad Gateway)?

Den Code 502 gibt es seit der ersten Spezifikation von HTTP/1.0, RFC 1945 vom Mai 1996. Heute definiert ihn RFC 9110, „HTTP Semantics“, vom Juni 2022 in Abschnitt 15.6.3. Dieses Dokument ersetzt die älteren Fassungen von HTTP/1.1.

Gateway und Proxy sind die beiden Rollen des Zwischenservers: Er nimmt die Anfrage entgegen, leitet sie an einen anderen Server weiter, den Ursprungsserver, und gibt dessen Antwort zurück. Ein CDN, ein Load Balancer oder ein Webserver wie nginx vor PHP übernehmen diese Rolle. Jeder zeigt den 502 mit einer eigenen Fehlerseite, der Code bleibt derselbe.

Auf einer heutigen Website läuft eine Anfrage durch mehrere Schichten: das CDN, manchmal einen Load Balancer, den Webserver und die Anwendung, die ihrerseits die Datenbank abfragt. Jede Schicht ist Client der nächsten. Den 502 erzeugt die Schicht, die auf eine Antwort gewartet und etwas Unbrauchbares bekommen hat, etwa eine abgebrochene Verbindung oder eine leere oder unvollständige Antwort.

Die Ursachen, die Hersteller in ihrer jeweiligen Doku nennen:

• Der Ursprungsserver ist abgestürzt, überlastet oder hat ein Netzwerkproblem, laut Cloudflares Seite zu den Fehlern 502 und 504.
• Die Anwendung beendet die Verbindung, bevor sie antwortet. Im Log von nginx steht dann „upstream prematurely closed connection“. Maxim Dounin, Entwickler bei nginx, schrieb 2012 auf der Mailingliste des Projekts, das liege meist an einem Absturz des Ursprungsservers oder an einem Prozess, der wegen eines Limits für Speicher, CPU oder Laufzeit beendet wurde.
• Das Gateway findet oder erreicht den Ursprungsserver nicht, zum Beispiel weil ein eigener DNS-Server dessen Namen nicht auflöst oder ein Health Probe scheitert. So beschreibt es Microsoft für Azure Application Gateway.
• Der Ursprung schickt kaputt komprimierte Inhalte oder eine falsche Inhaltslänge. Laut Cloudflare entsteht daraus ein 502, den Cloudflare selbst erzeugt.

Der Text der Fehlermeldung hilft wenig. Entscheidend ist, welche Schicht den Fehler erzeugt hat, und dafür gibt es drei Hinweise.

Der erste sind die Header der Antwort. Der Header Server nennt die Software, die geantwortet hat, und Via zeigt laut RFC 9110 die Zwischenstationen, über die die Nachricht lief. Cloudflare setzt zusätzlich Cf-Ray mit dem Rechenzentrum, das die Anfrage bearbeitet hat.

Der zweite ist die Fehlerseite. Cloudflare dokumentiert: Ein 502 mit Cloudflare-Logo kommt vom Ursprungsserver, der ihn so weitergegeben hat. Eine leere Seite ohne Logo erzeugt Cloudflare selbst.

Der dritte ist das Log des Webservers. Wenn nginx notiert, dass der Ursprung die Verbindung geschlossen hat, liegt der Fehler in der Anwendung dahinter und nicht bei nginx.

Ein Shop mit Cloudflare davor und nginx mit PHP auf dem Server zeigt auf allen Produktseiten einen 502. Die Antwort trägt Server: cloudflare und Cf-Ray, die Seite hat das Cloudflare-Logo: Der Fehler kommt vom Ursprung. Im nginx-Log steht zur selben Zeit „upstream prematurely closed connection“, im PHP-Log ein Prozess, der am Speicherlimit abgebrochen wurde: Die Ursache liegt in der Anwendung.

Ein anderer Fall: Derselbe Shop liefert eine leere Seite mit 502, ohne Logo. Laut Cloudflare kommt diese Antwort aus seinem eigenen Netz, und eine mögliche Ursache ist eine fehlerhafte Komprimierung am Ursprung.

Im Terminal zeigt curl -I https://www.example.com/ den Code und die Header Server, Via oder Cf-Ray. Ob das Problem im CDN oder am Ursprung liegt, siehst du, wenn du dieselbe Anfrage direkt an den Ursprungsserver schickst, am CDN vorbei.

In der Google Search Console fasst der Bericht zur Seitenindexierung diese Fehler unter „Server error (5xx)“ (Serverfehler) zusammen. Vereinzelte 502 siehst du besser in der Crawling-Statistik beim Hoststatus: Das Diagramm zur Serververbindung zeigt, wann der Server nicht oder nicht vollständig geantwortet hat.

Niemand wählt einen 502 so, wie man für eine Wartung einen 503 wählt: Der 502 ist ein Symptom. Sein einziger Nutzen liegt in der Diagnose: Der Code sagt schon, dass der Fehler zwischen zwei Servern liegt, und mit den Headern grenzt du ein, auf welchem Abschnitt.

Für SEO behandelt Google ihn wie jeden Serverfehler. Die Google-Doku zu Statuscodes beschreibt für 500, 502 und 503 dieselbe Wirkung: Googles Crawler werden langsamer, laut der Anleitung zum Senken der Crawling-Frequenz gilt das für den ganzen Hostnamen, und indexierte URLs bleiben erhalten, „but eventually dropped“. Für den 502 nennt Google keine Frist. Was bei einem Serverfehler über mehrere Tage passiert, steht im Eintrag zu Fehler 503.

Quelle: RFC 9110 (Juni 2022), Abschnitte 15.6.3 und 15.6.5; Cloudflare, „Cloudflare 5xx errors“, „Error 520“ und „Error 521“ (abgerufen am 12.11.2026).

Der 500 ist der allgemeine Fehler des Servers selbst, und der 503 sagt, dass der Server wegen Überlastung oder Wartung gerade nicht antworten kann. Ein Beispiel: Sperrt die Firewall des Ursprungs die IP-Adressen von Cloudflare, zeigt Cloudflare einen 521 statt eines 502.

Keine der gelesenen Quellen sagt, welche Ursache am häufigsten ist. Aussagen wie „ein 502 ist fast immer ein Hosting-Problem“ sind deshalb nicht belegt. Cloudflares Doku nennt Fehler am Ursprung ebenso wie Fehler im eigenen Netz.

Für den 502 gibt es auch keine veröffentlichte Frist. Google sagt nicht, wie viele Tage mit 502 es hinnimmt, bevor es eine URL entfernt. Es schreibt nur, dass die URLs bei anhaltendem Fehler irgendwann herausfallen („eventually“). Nur für 503 und 429 spricht seine Seite zu Crawling-Fehlern von mehr als zwei Tagen.

• Prüf mit curl, welche Header der 502 mitbringt und ob die Seite das Logo des CDN trägt.
• Schick dieselbe Anfrage direkt an den Ursprung, ohne CDN.
• Such im Log des Webservers dieselbe Uhrzeit und die Meldung des Proxys.
• Sieh im Log der Anwendung nach, ob ein Prozess wegen Speicher, CPU oder Laufzeit beendet wurde.
• Vergleich das Timeout des Proxys mit der Antwortzeit der Anwendung; Microsoft nennt das überschrittene Timeout als eine Ursache für 502 in Azure Application Gateway.
• Prüf nach der Behebung in der Search Console den Hoststatus in der Crawling-Statistik.
• Wenn du die Seite nur besuchst: Lade sie nach ein paar Minuten neu.

• Schreib die Logs von Webserver und Anwendung in derselben Zeitzone, damit du sie abgleichen kannst.
• Wenn eine Wartung den Ursprung abschaltet, liefere bewusst einen 503, statt das CDN einen 502 zeigen zu lassen.

• Den Fehler im CDN suchen, obwohl dessen eigene Fehlerseite sagt, dass er vom Ursprung kommt.
• Einen 502 für ein Problem im Browser des Besuchers halten.
• Annehmen, dass Google einen 502 milder behandelt als einen 500 oder 503.

Dieser Eintrag entstand im November 2026 mit Unterstützung von KI. Die Angaben stammen aus RFC 1945 und RFC 9110, aus Googles Doku zu Statuscodes und Crawling-Frequenz, aus der Search-Console-Hilfe und aus der Doku von MDN, Cloudflare, Microsoft und nginx. Er wurde vor der Veröffentlichung geprüft und enthält keine Kundendaten.