502 Bad Gateway: Bedeutung und so behebst du den Fehler

Was ist ein 502-Bad-Gateway-Fehler?

502 Bad Gateway ist ein HTTP-Statuscode, der bedeutet: Der Server, der dir 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 deine 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 dir nichts zu liefern – also gibt er 502 zurück.

Der entscheidende Punkt: Das Gateway selbst funktioniert. Es hat deine 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 du siehst, hängt davon ab, welcher Proxy sie erzeugt hat:

Egal welche Variante du siehst: 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 fehlerhaft geantwortet (oder aufgelegt), 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 können also nirgendwohin.

• 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.

• Eine Firewall- oder Netzwerkänderung zwischen Proxy und Origin. Zum Beispiel erreicht ein CDN einen Origin-Server nicht mehr, dessen IP-Adresse oder Firewall-Regeln sich geändert haben.

So behebst du einen 502-Fehler als Besucher

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

• Warte 30 bis 60 Sekunden und lade neu (Strg + R, auf dem Mac Cmd + R). Viele 502-Fehler dauern nur so lange wie ein Deployment oder ein Neustart.

• Prüfe, ob die Seite für alle down ist. Das Tool HTTP-Headers von DNS Robot ruft die Seite von unseren Servern ab und zeigt den genauen Statuscode. Bekommen wir auch einen 502, liegt es an der Seite, nicht an dir. Ein Ping-Test zeigt, ob die Servermaschine überhaupt antwortet.

• Lade hart neu und leere den Cache. Strg + Umschalt + R (Mac: Cmd + Umschalt + R) umgeht die zwischengespeicherte Kopie, falls dir eine veraltete Fehlerseite angezeigt wird.

• Leere deinen DNS-Cache, wenn die Seite kürzlich den Hoster gewechselt hat, damit du den neuen Server erreichst. Hier steht, wie du den DNS-Cache leerst – für jedes System.

• Schalte VPNs und Proxys aus. Dein eigener Proxy kann das „Gateway“ sein, das versagt, besonders in Firmennetzen.

• Probiere einen anderen Browser oder dein Smartphone über mobile Daten. Funktioniert es dort, lösche die Cookies dieser Seite.

So behebst du einen 502 Bad Gateway auf deinem Server

Serverseitig gehört ein 502 zu den leichter zu behebenden Fehlern, weil der Proxy fast immer genau notiert, was schiefgelaufen ist. Arbeite diese vier Prüfungen der Reihe nach ab.

1. Das Fehlerlog des Proxys lesen

Reproduziere den 502 und lies dann die letzten Zeilen des Fehlerlogs auf dem Proxy-Server:

# 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

Diese nginx-Meldungen decken die große Mehrheit aller 502-Fehler ab, und jede führt direkt zur Lösung:

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?
dmesg -T | grep -i "killed process"

Ist der Dienst gestoppt, starte ihn und finde 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öhe pm.max_children nur, wenn der Server genug RAM dafür hat – ansonsten finde die langsamen Anfragen, die die Worker blockieren.

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

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

# Wohin leitet nginx weiter?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# 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 – nutze dort den Namen des Compose-Service (http://app:3000). Führe nach jeder Änderung sudo nginx -t und sudo systemctl reload nginx aus.

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:

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;
}

Nach nginx -t und einem Reload lieferte die Seite 200. Die Lehre daraus: Liefern nur einige Seiten einen 502, während der Rest der Website funktioniert, such nach einem Größenlimit, etwa großen Headern oder Cookies auf diesen Seiten, bevor du die App verdächtigst.

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

Betreibst du Node.js hinter einem AWS Application Load Balancer oder einem ähnlichen Balancer und siehst gelegentlich 502-Fehler ohne Einträge in deinen App-Logs, prüfe 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), 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 // knapp über keepAliveTimeout halten

502 Bad Gateway bei Cloudflare

Hinter Cloudflare schaust du zuerst, wer die Fehlerseite erzeugt hat:

• Seite im Cloudflare-Design (Browser ✓ / Cloudflare ✓ / Host ✗): Cloudflare funktioniert, hat aber von deinem Origin-Server keine gültige Antwort bekommen. Prüfe, ob der Origin läuft, auf 443/80 lauscht und die IP-Bereiche von Cloudflare nicht in seiner Firewall blockiert. Teste den Origin direkt mit dem Port-Checker.

• Schlichte 502-Seite ohne Branding: Erwähnt sie cloudflare nicht (nennt sie zum Beispiel nginx oder Apache), hat dein eigener Origin-Server den 502 erzeugt. Nutze die serverseitigen Schritte oben. Eine leere Seite, auf der unten nur „cloudflare“ steht, kommt von Cloudflare selbst, zum Beispiel bei einer kurzen Umleitung des Traffics oder wenn der Origin fehlerhaften gzip-Inhalt sendet.

• Hat sich die Origin-IP geändert? Wenn du den Hoster gewechselt hast, aktualisiere den A-Record im DNS von Cloudflare. Ein DNS-Lookup zeigt, was die Welt aktuell sieht.

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. Überwache deine wichtigsten URLs und prüfe nach jedem Ausfall den Bericht „Crawling-Statistiken“ in der Search Console.