502 Bad Gateway: Was es wirklich bedeutet und wie du es behebst
Du öffnest deine Website und siehst statt des Inhalts eine leere Seite mit der Meldung 502 Bad Gateway. Das klingt schlimmer als es ist — in den meisten Fällen ist die Lösung ganz einfach. Lass uns erklären, was passiert und wie du deine Website wieder zum Laufen bringst.
Was bedeutet 502 eigentlich?
Wenn ein Besucher eine Seite aufruft, durchläuft die Anfrage zwei Schichten: einen Frontend-Webserver (meist Nginx) und einen Backend-Applikationsserver (PHP-FPM, Apache, Node.js oder ähnliches). Nginx empfängt die Anfrage, leitet sie an das Backend weiter und wartet auf eine Antwort.
502 Bad Gateway bedeutet, dass Nginx versucht hat, eine Antwort vom Backend zu bekommen, aber entweder eine ungültige Antwort erhalten hat oder gar keine. Das Backend ist abgestürzt, hat die Verbindung verweigert oder etwas zurückgegeben, das Nginx nicht verarbeiten konnte.
Ein weit verbreitetes Missverständnis: 502 bedeutet nicht, dass dein Server ausgefallen ist. Der Server selbst funktioniert einwandfrei — das Problem liegt bei der Anwendung hinter Nginx.
Die häufigsten Ursachen
Der Backend-Dienst ist gestoppt. Das ist der häufigste Grund. PHP-FPM ist abgestürzt, Apache hängt oder ein Node.js-Prozess ist stillschweigend beendet worden. Nginx hat schlicht nichts, mit dem es kommunizieren kann.
Dem Server geht der Arbeitsspeicher aus. Wenn der Speicher knapp wird, kann Linux ressourcenintensive Prozesse automatisch beenden. Dieser Mechanismus heißt OOM Killer, und PHP-FPM oder MySQL sind meist die ersten Opfer. Wenn das regelmäßig passiert, solltest du eine Swap-Datei hinzufügen — das dient als Sicherheitsnetz.
Der PHP-FPM Worker-Pool ist erschöpft. Wenn deine Website mehr gleichzeitige Anfragen erhält, als PHP-FPM bewältigen kann, stauen sich neue Anfragen auf und laufen schließlich in einen Timeout. Das passiert oft, wenn Suchmaschinen-Bots deine Website zu aggressiv crawlen — dazu haben wir einen eigenen Bot-Blocking-Guide geschrieben.
Falscher Socket oder Port konfiguriert. Nginx erwartet PHP-FPM auf einem bestimmten Unix-Socket oder TCP-Port. Stimmt der Pfad in der Nginx-Konfiguration nicht mit der PHP-FPM-Konfiguration überein, erscheinen 502-Fehler sofort nach jeder Änderung.
Wie du das Problem diagnostizierst
Für die folgenden Schritte musst du dich per SSH mit deinem Server verbinden. Wie das geht, erklärt unser SSH-Artikel.
Schritt 1. Prüfe, ob das Backend läuft
Überprüfe den Status deines Backend-Dienstes:
sudo systemctl status php8.2-fpm
Ersetze php8.2-fpm durch deine tatsächliche PHP-Version oder den Namen deines Backend-Dienstes. Wenn die Ausgabe inactive (dead) oder failed zeigt, hast du die Ursache gefunden. Starte den Dienst neu:
sudo systemctl restart php8.2-fpm
Überprüfe danach den Status erneut, um sicherzustellen, dass der Dienst erfolgreich gestartet wurde.
Schritt 2. Prüfe das Nginx Error-Log
Das Error-Log verrät dir fast immer genau, was schiefgelaufen ist:
sudo tail -30 /var/log/nginx/error.log
Wenn du FASTPANEL® verwendest, kannst du die Logs auch direkt im Webinterface einsehen: Öffne die Website-Karte, gehe zum Bereich „Logs" und schaue in den Tab „Frontend Error Log".
Hier sind die häufigsten Fehlermeldungen und ihre Bedeutung:
connect() failed - Connection refused — der Backend-Dienst läuft nicht. Starte ihn wie in Schritt 1 neu.
connect() failed - No such file or directory — Nginx versucht, einen Unix-Socket zu erreichen, der nicht existiert. Überprüfe, ob der Socket-Pfad in deiner Nginx-Konfiguration mit dem übereinstimmt, den PHP-FPM tatsächlich anlegt.
upstream sent too big header — das Backend hat HTTP-Header zurückgegeben, die zu groß für den Standard-Puffer sind. Füge diese Zeilen in deiner Nginx-Site-Konfiguration innerhalb des server-Blocks ein:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
Nach der Bearbeitung teste die Konfiguration und lade Nginx neu:
sudo nginx -t && sudo systemctl reload nginx
Schritt 3. Prüfe die Server-Ressourcen
free -h
Wenn die Spalte available weniger als 100–200 MB freien Speicher anzeigt, geht dem Server wahrscheinlich der RAM aus. Überprüfe, was ihn verbraucht:
ps aux --sort=-%mem | head -10
Wenn Speichermangel die Ursache ist, ist die schnellste kurzfristige Lösung das Hinzufügen einer Swap-Datei. Swap auf der Festplatte ist jedoch deutlich langsamer als RAM und keine dauerhafte Lösung. Wenn dein Server regelmäßig keinen Speicher mehr hat, solltest du entweder deine Anwendungen optimieren oder auf einen Plan mit mehr RAM umsteigen.
Fazit
Ein 502 Bad Gateway ist fast immer ein Backend-Problem — ein abgestürzter Dienst, erschöpfte Worker oder zu wenig Arbeitsspeicher. Überprüfe den Backend-Status, lies das Nginx Error-Log und schau dir deine Ressourcennutzung an. In den allermeisten Fällen findest du die Antwort innerhalb weniger Minuten.
Wenn du das lieber nicht alleine angehen möchtest, bieten wir bei kodu.cloud kostenlosen 24/7-Support zu jedem VPS und dedizierten server. Alle unsere Kunden erhalten außerdem FASTPANEL® Extended ohne Aufpreis — das macht Log-Analyse und Dienstverwaltung über ein übersichtliches Webinterface deutlich einfacher.