502 Bad Gateway: Ursachen, Diagnose und Lösungen

Was ist ein 502 Bad Gateway?

Wenn ein Browser die Fehlermeldung „502 Bad Gateway” anzeigt, hat der angefragte Server als Vermittler zwischen Client und einem weiteren Server versagt. Der Proxy, Load Balancer oder das CDN hat vom dahinterliegenden Backend-Server entweder keine Antwort, eine fehlerhafte Antwort oder eine Antwort mit einem unbekannten Protokoll erhalten.

Der Statuscode 502 gehört zur 5xx-Fehlerklasse, die serverseitige Probleme beschreibt. Der Client hat seinen Teil korrekt ausgeführt, die Anfrage ist gültig und das Problem liegt ausschließlich in der Server-Infrastruktur.

Technischer Hintergrund: Warum tritt 502 auf?

Moderne Webanwendungen bestehen aus mehreren Schichten. Eine typische Kette sieht so aus:

Browser anfrage geht an CDN (z. B. Cloudflare), von dort an einen Nginx-Reverse-Proxy, von dort an den eigentlichen Anwendungsserver (z. B. Node.js oder PHP-FPM). Bricht diese Kette an irgendeiner Stelle, entsteht ein 502-Fehler beim Glied, das die Kommunikation nicht herstellen kann.

Häufige technische Auslöser:

1. Backend-Server antwortet nicht Der Anwendungsserver (Apache, Node.js, Gunicorn) ist abgestürzt oder wurde neu gestartet. Der Proxy wartet auf eine Verbindung, die nicht zustande kommt, und gibt nach einem Timeout 502 zurück.

2. Timeout überschritten Langsame Datenbankabfragen oder aufwändige Berechnungen können dazu führen, dass der Backend-Server die Antwort nicht rechtzeitig liefert. Der Proxy-Server bricht die Verbindung ab.

3. Überlastung des Backend-Servers Zu viele gleichzeitige Anfragen überlasten den Anwendungsserver. Neue Verbindungen werden abgelehnt oder nicht rechtzeitig bearbeitet.

4. Netzwerkprobleme zwischen Gateway und Backend Firewall-Regeln, falsche interne DNS-Auflösung oder Netzwerkpartitionen können verhindern, dass das Gateway den Backend-Server erreicht.

5. Konfigurationsfehler Falsche Upstream-Adressen in Nginx oder Apache, falsch konfigurierte Load-Balancer-Regeln oder Versionskonflikte zwischen Proxy und Backend können ebenfalls 502-Fehler verursachen.

Diagnose: Wie lokalisiert man die Ursache?

Für Website-Betreiber beginnt die Diagnose mit den Server-Logs. Bei Nginx findet man relevante Einträge im Error-Log:

tail -f /var/log/nginx/error.log

Typische Einträge bei einem 502 sind Meldungen wie connect() failed (111: Connection refused) oder upstream timed out.

Für Prozess-Status lohnt ein Blick auf den Backend-Dienst:

systemctl status php8.2-fpm
systemctl status gunicorn
pm2 status

Bei CDN-Zwischenschichten wie Cloudflare zeigt das Dashboard direkt an, ob der Origin-Server erreichbar ist. Mit dem Tool auf dieser Seite kann man schnell prüfen, ob eine Domain grundsätzlich antwortet, oder ob der Fehler bei einem bestimmten Pfad entsteht.

Lösungsansätze je nach Ursache

Abgestürzter Backend-Dienst: Neustart des betroffenen Dienstes, z. B.:

systemctl restart php8.2-fpm

Danach die Logs prüfen, warum der Dienst abgestürzt ist.

Timeout-Konfiguration anpassen: In Nginx kann man den Timeout für Upstream-Verbindungen erhöhen:

proxy_read_timeout 120s;
proxy_connect_timeout 10s;

Überlastung beheben: Kapazität des Backend-Servers erhöhen oder die Anzahl gleichzeitiger Worker-Prozesse anpassen. Bei kurzfristiger Überlastung hilft ein Warteschlangen-Mechanismus.

Upstream-Adresse korrigieren: Sicherstellen, dass die Proxy-Konfiguration auf die korrekte interne IP-Adresse und den richtigen Port zeigt. Ein Tippfehler in der Nginx-Config ist häufiger als man denkt.

Was Besucher selbst tun können

Als Besucher einer Website hat man wenig Einfluss auf einen 502-Fehler. Folgende Schritte sind dennoch sinnvoll:

Die Seite nach einigen Minuten erneut laden. Bei kurzfristiger Überlastung normalisiert sich der Betrieb oft schnell. Browser-Cache und Cookies leeren, um veraltete Fehlerseiten zu vermeiden. Mit einem anderen Gerät oder Netzwerk prüfen, ob der Fehler überall auftritt. Die offizielle Statusseite des Dienstes besuchen, falls vorhanden.

502 vs. verwandte Statuscodes

Der 502-Fehler wird manchmal mit anderen Codes verwechselt. Hier ein kurzer Vergleich:

503 Service Unavailable: Server ist bewusst nicht verfügbar, oft mit einer Wartungsseite. Der Unterschied zu 502 ist, dass hier kein Gateway-Problem vorliegt, sondern der Server selbst Überlastung oder geplante Downtime meldet.

504 Gateway Timeout: Ähnlich wie 502, aber hier hat der Gateway-Server eine Zeitüberschreitung beim Warten auf den Backend-Server. Bei 502 war die Antwort invalid, bei 504 kam gar keine Antwort rechtzeitig.

500 Internal Server Error: Der Server selbst hat einen Fehler gemacht, ohne Gateway-Beteiligung.

Prävention und Monitoring

Damit ein 502-Fehler nicht unbemerkt bleibt, empfiehlt sich ein kontinuierliches Monitoring. Checks alle ein bis fünf Minuten sind für die meisten Websites ausreichend. Bei kritischen Anwendungen können kürzere Intervalle sinnvoll sein.

Wichtige Monitoring-Aspekte:

HTTP-Statuscode prüfen, ob er im 2xx-Bereich liegt. Antwortzeit messen, da ein stark ansteigender Wert oft ein Vorläufer von 502-Fehlern ist. Endpunkt-spezifische Checks für kritische Seiten wie Login oder API-Endpunkte einrichten.

Ein gut konfiguriertes Alerting informiert das Team sofort per E-Mail oder Messenger, wenn ein 502 auftritt, sodass die Reaktionszeit minimiert wird.