502 Bad Gateway: Bedeutung und so beheben Sie den Fehler

Was ist ein 502-Bad-Gateway-Fehler?

502 Bad Gateway ist ein HTTP-Statuscode, der bedeutet: Der Server, der Ihnen antwortet, arbeitet als Gateway oder Proxy und hat vom Server dahinter eine ungültige Antwort erhalten. Der HTTP-Standard (RFC 9110, Abschnitt 15.6.3) definiert ihn genau so: Der Server hat, „während er als Gateway oder Proxy agierte, eine ungültige Antwort von einem eingehenden Server erhalten, auf den er beim Versuch, die Anfrage zu erfüllen, zugegriffen hat“.

Die meisten modernen Websites haben mindestens zwei Schichten. Ein Frontserver wie nginx, Apache, Cloudflare oder ein Cloud-Load-Balancer nimmt Ihre Verbindung an und reicht die Anfrage an eine Upstream-Anwendung weiter, etwa PHP-FPM, eine Node.js-App, Pythons Gunicorn oder einen Container. Ist dieser Upstream down, stürzt er ab oder antwortet er mit etwas, das der Proxy nicht verwenden kann, hat der Proxy Ihnen nichts zu liefern – also gibt er 502 zurück.

Der entscheidende Punkt: Das Gateway selbst funktioniert. Es hat Ihre Anfrage empfangen und geantwortet. Der Fehler liegt einen Schritt weiter hinten.

Die vielen Gesichter eines 502-Fehlers

Der Statuscode ist überall derselbe, aber welche Seite Sie sehen, hängt davon ab, welcher Proxy sie erzeugt hat:

Egal welche Variante Sie sehen: Der Name des Proxys in der Fußzeile ist ein nützlicher Hinweis – er verrät dem Betreiber, welche Schicht er untersuchen muss.

502 vs. 500 vs. 503 vs. 504: Was ist der Unterschied?

Alle 5xx-Codes bedeuten „Serverproblem“, aber jeder zeigt auf eine andere Schicht:

Eine schnelle Faustregel: 502 = der Upstream hat die Verbindung verweigert, aufgelegt oder fehlerhaft geantwortet, 504 = der Upstream hat nicht rechtzeitig geantwortet. Unsere Anleitungen zu den verwandten Codes gehen ins Detail: 500 Internal Server Error, 503 Service Unavailable und 504 Gateway Timeout.

Was verursacht einen 502 Bad Gateway?

• Die Upstream-App läuft nicht. PHP-FPM, Node, Gunicorn oder der Container ist abgestürzt, nach einem Deployment nicht gestartet oder startet gerade neu.
• Der Proxy zeigt an die falsche Stelle. proxy_pass oder fastcgi_pass nutzt den falschen Port, nach einem Upgrade einen alten PHP-Socket-Pfad oder localhost innerhalb eines Docker-Containers.
• Die App stürzt bei bestimmten Anfragen ab. Eine Seite löst einen Out-of-Memory-Kill oder eine unbehandelte Exception aus, und die Verbindung schließt sich vor der Antwort.
• Alle Worker sind belegt. PHP-FPM hat pm.max_children erreicht, neue Anfragen warten in der Warteschlange des Sockets. Die meisten laufen danach als 504 in ein Timeout; ist die Warteschlange voll, protokolliert nginx (11: Resource temporarily unavailable) und liefert 502.
• Die Response-Header sind zu groß. Große Cookies oder umfangreiche Security-Header sprengen die proxy_buffer_size von nginx.
• Keep-Alive-Konflikt hinter einem Load Balancer. Die App schließt Leerlauf-Verbindungen früher, als der Load Balancer erwartet, sodass er eine Anfrage in eine Verbindung schickt, die gerade geschlossen wird.
• Der Proxy erreicht den Upstream nach einer Netzwerkänderung nicht mehr. Eine Firewall, die den Proxy abweist, oder ein Upstream mit neuer IP führt zu 502 (Connection refused, No route to host). Eine Firewall, die Pakete stillschweigend verwirft, führt stattdessen zu 504, und hinter Cloudflare erscheinen diese Fälle als 521 oder 522.

So beheben Sie einen 502-Fehler als Besucher

Den Server eines anderen können Sie nicht reparieren, aber diese Schritte bestätigen, dass das Problem wirklich dort liegt, und beseitigen die seltenen lokalen Ursachen:

• Warten Sie 30 bis 60 Sekunden und laden Sie neu (Strg + R, auf dem Mac Cmd + R). Viele 502-Fehler dauern nur so lange wie ein Deployment oder ein Neustart.
• Prüfen Sie, ob die Seite für alle down ist. Der Website-Down-Checker von DNS Robot ruft die Seite von 11 Standorten aus auf, und der HTTP-Header-Checker zeigt den genauen Statuscode, den unser Server erhält. Sehen auch sie einen 502, liegt es an der Seite, nicht an Ihnen.
• Laden Sie hart neu mit Strg + Umschalt + R (Mac: Cmd + Umschalt + R), falls Ihnen im seltenen Fall eine zwischengespeicherte Fehlerseite angezeigt wird.
• Leeren Sie Ihren DNS-Cache, wenn die Seite kürzlich den Hoster gewechselt hat, damit Sie den neuen Server erreichen. Hier steht, wie Sie den DNS-Cache leeren – für jedes System.
• Schalten Sie VPNs und Proxys aus. Ihr eigener Proxy kann das „Gateway“ sein, das versagt, besonders in Firmennetzen.
• Probieren Sie einen anderen Browser oder Ihr Smartphone über mobile Daten. Funktioniert es dort, löschen Sie die Cookies dieser Seite.

So beheben Sie einen 502 Bad Gateway auf Ihrem Server

Serverseitig gehört ein 502 zu den leichter zu behebenden Fehlern, weil der Proxy meist protokolliert, was schiefgelaufen ist (Ausnahmen sind eine Keep-Alive-Race-Condition beim Load Balancer und Cloudflares eigene 502). Arbeiten Sie diese drei Prüfungen der Reihe nach ab; der vierte Teil ist ein echtes Beispiel.

1. Das Fehlerlog des Proxys lesen

Reproduzieren Sie den 502 und lesen Sie dann die letzten 50 Zeilen des Fehlerlogs des Proxys (Befehle unter der Tabelle). Jede dieser nginx-Meldungen führt zu einer eigenen Lösung:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Prüfen, ob die Upstream-App läuft

# PHP-FPM (Version anpassen)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js unter PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # nach Containern suchen, die ständig neu starten
docker logs --tail 50 <container>

# Wurde sie wegen zu hohen Speicherverbrauchs beendet?
sudo dmesg -T | grep -i "killed process"

Ist der Dienst gestoppt, starten Sie ihn und finden Sie heraus, warum er gestoppt wurde: ein fehlgeschlagenes Deployment, ein Syntaxfehler im neuen Release oder der Out-of-Memory-Killer. Im Log von PHP-FPM bedeutet server reached pm.max_children setting, dass alle Worker belegt waren. Erhöhen Sie pm.max_children nur, wenn der Server genug RAM dafür hat – ansonsten finden Sie die langsamen Anfragen, die die Worker blockieren.

3. Sicherstellen, dass proxy_pass auf den richtigen Port oder Socket zeigt

Vergleichen Sie, womit nginx sprechen soll, mit dem, was tatsächlich lauscht:

# Wohin leitet nginx weiter?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# Was lauscht tatsächlich?
sudo ss -tlnp            # TCP-Ports und ihre Prozesse
ls -l /run/php/          # PHP-FPM-Socket-Dateien

Zwei klassische Unstimmigkeiten: Nach einem PHP-Upgrade heißt der Socket php8.3-fpm.sock, während nginx noch auf php8.1-fpm.sock zeigt; und innerhalb von Docker zeigt proxy_pass http://localhost:3000 auf den nginx-Container selbst statt auf die App – nutzen Sie dort den Namen des Compose-Service (http://app:3000).

4. Ein echtes Beispiel: Wie dnsrobot.net einen 502 auslieferte

Das ist uns am 30. September 2026 passiert. Nachdem wir einen Schwung neuer Blogartikel veröffentlicht hatten, lieferte genau einer davon über nginx 1.24 502 Bad Gateway, während jede andere Seite funktionierte. Die Next.js-App hinter nginx lieferte dieselbe Seite mit 200 OK, als wir sie direkt auf Port 3000 abriefen. Die App war also in Ordnung, und das Gateway scheiterte.

Das nginx-Fehlerlog hatte die Antwort in einer Zeile: upstream sent too big header while reading response header from upstream. Die Response-Header dieser Seite kamen auf 4.087 Byte, überwiegend ein langer Content-Security-Policy-Header plus Preload-Link-Header. nginx liest den ersten Teil der Antwort einschließlich aller Header in einen Puffer, dessen Größe proxy_buffer_size festlegt – standardmäßig eine Speicherseite: 4 KB auf unserem Server. Damit blieben nur 9 Byte Luft, und der komplette Header-Block samt Statuszeile lief über.

Die Lösung waren drei Zeilen im location-Block, der an die App weiterleitet; nach nginx -t und einem Reload lieferte die Seite 200:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # Platz für große Header (vorher der 4k-Standard)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

Die Lehre daraus: Liefern nur einige Seiten einen 502, während der Rest der Website funktioniert, suchen Sie nach einem Größenlimit, etwa großen Headern oder Set-Cookie-Werten auf diesen Seiten, bevor Sie die App verdächtigen.

Node.js hinter einem Load Balancer: Sporadische 502-Fehler

Betreiben Sie Node.js hinter einem AWS Application Load Balancer oder einem ähnlichen Balancer und sehen gelegentlich 502-Fehler ohne Einträge in Ihren App-Logs, prüfen Sie die Keep-Alive-Timeouts. Der HTTP-Server von Node schließt Leerlauf-Keep-Alive-Verbindungen standardmäßig nach 5 Sekunden (server.keepAliveTimeout, in Node.js 26 und früher; Node 24.6 und 22.19 haben zusätzlich einen keepAliveTimeoutBuffer von 1 Sekunde eingeführt, und das nächste Major-Release erhöht den Standardwert auf 65 Sekunden), während ein AWS ALB Leerlauf-Verbindungen 60 Sekunden offen hält. Manchmal verwendet der Balancer eine Verbindung genau in dem Moment wieder, in dem Node sie schließt, und diese Anfrage kommt als 502 zurück.

Die Lösung: Das Timeout der App muss länger sein als das des Balancers:

const server = app.listen(3000)
// Muss länger sein als das Leerlauf-Timeout des Load Balancers (ALB-Standard: 60s)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // nur vor Node 18 nötig; danach unschädlich

502 Bad Gateway bei Cloudflare

Hinter Cloudflare schauen Sie zuerst, wer die Fehlerseite erzeugt hat (Cloudflares 502/504-Leitfaden):

• Seite im Cloudflare-Design (Browser ✓ / Cloudflare ✓ / Host ✗): Ihr Origin-Server selbst hat Cloudflare einen 502 oder 504 geliefert. Beheben Sie das am Origin mit den serverseitigen Schritten oben. Kann Cloudflare den Origin gar nicht erreichen, erscheint 521 oder 522, nicht 502.
• Eine schlichte Seite mit „502 Bad Gateway“ und darunter „cloudflare“: Sie stammt von Cloudflare selbst. Cloudflares Dokumentation nennt zwei Ursachen: Ihr Origin sendet fehlerhaften gzip-Inhalt oder gzip-Inhalt ohne aktualisierte Content-Length (zum Testen die Kompression am Origin ausschalten), und eine plötzliche Lastspitze an einem Cloudflare-Rechenzentrum, die von selbst vergeht.
• Eine Seite, die nginx oder Apache nennt: Meist hat die Anfrage Ihren Server ohne Umweg über Cloudflare erreicht, weil der DNS-Eintrag nicht geproxyt ist (graue Wolke) oder Sie direkt den Origin ansehen (es sei denn, eine Cache Rule aktiviert „Origin error page pass-through“).
• Hoster gewechselt? Aktualisieren Sie den A-Record des Origins im DNS von Cloudflare (eine falsche Origin-IP zeigt sich meist als 521, 522 oder 523). Ein DNS-Lookup zeigt den Origin nur bei Einträgen mit grauer Wolke (nur DNS); geproxyte Einträge antworten mit Cloudflares eigenen IPs.

Schadet ein 502-Fehler der SEO?

Ein kurzer Ausfall nicht. Laut Googles Dokumentation führen 5xx-Serverfehler dazu, dass die Crawler das Crawling vorübergehend verlangsamen. Bereits indexierte Seiten bleiben zunächst im Index, aber wenn die Fehler bestehen bleiben, entfernt Google diese URLs irgendwann.

Ein 502, der während eines Deployments ein paar Minuten dauert, ist also harmlos. Ein 502 auf wichtigen Seiten, der tagelang anhält oder wochenlang sporadisch auftritt, kann das Crawling reduzieren und Rankings kosten. Überwachen Sie Ihre wichtigsten URLs und prüfen Sie nach jedem Ausfall den Bericht „Crawling-Statistiken“ in der Search Console.