Dein Preis in 2 Minuten

WordPress-Fehler502

WordPress zeigt 502 Bad Gateway: Ursache finden und Seite zurückholen

Ein 502 Bad Gateway heißt: Ein vorgeschalteter Server wie nginx, ein Load Balancer oder Cloudflare hat bei PHP nachgefragt und keine brauchbare Antwort bekommen. Bei WordPress sind meist abgestürzte oder ausgelastete PHP-Prozesse schuld, oft ausgelöst durch ein Plugin, eine lange Aufgabe oder viele gleichzeitige Besucher. Manchmal erreicht Cloudflare den Server gar nicht. Warte kurz und lade neu. Lies danach das Fehlerprotokoll des Servers und schalte Plugins testweise ab. Hält der Fehler an, muss PHP neu gestartet oder großzügiger eingestellt werden.

So sieht die Meldung aus

  • 502 Bad Gateway
  • HTTP ERROR 502
  • Error code 502
  • The proxy server received an invalid response from an upstream server.

Woran es liegt.

PHP-Prozesse abgestürzt oder ausgelastet

nginx reicht jede Anfrage an PHP-FPM weiter. Sind alle PHP-Prozesse belegt oder ist der Dienst abgestürzt, kommt nichts Brauchbares zurück und nginx meldet 502. Im Protokoll von PHP-FPM steht dann oft „server reached pm.max_children setting“.

Plugin oder Theme bringt PHP zum Absturz

Ein fehlerhaftes Plugin kann den PHP-Prozess mitten in der Anfrage beenden, etwa durch eine Endlosschleife oder einen Fehler in einer PHP-Erweiterung. nginx sieht nur eine abgebrochene Verbindung und liefert statt der Seite den Fehler 502.

Zu große Antwort-Header

Setzen Plugins viele Cookies oder sehr lange Header, passen sie nicht mehr in den Puffer von nginx. Das Fehlerprotokoll zeigt dann „upstream sent too big header while reading response header from upstream“. Häufig trifft es nur einzelne Bereiche wie den Login oder den Warenkorb.

Cloudflare erreicht den Server nicht sauber

Die Fehlerseite von Cloudflare zeigt drei Stationen: Browser, Cloudflare und Host. Steht unter „Host“ das Wort „Error“, antwortet Dein Server nicht richtig. Gründe sind eine Firewall, die Cloudflare aussperrt, eine falsche IP-Adresse im DNS oder ein Ausfall beim Hoster.

Lastspitze oder Neustart beim Hoster

Bei einem Besucheransturm, Bot-Wellen oder während der Hoster PHP neu startet, bleiben Anfragen kurz unbeantwortet. Solche 502-Fehler verschwinden oft nach wenigen Minuten von selbst. Sie kehren aber wieder, wenn das Paket dauerhaft zu knapp bemessen ist.

So behebst Du den Fehler.

Leg vor jeder Änderung eine Sicherung von Dateien und Datenbank an. Geh die Schritte der Reihe nach durch und prüf nach jedem, ob die Seite wieder lädt.

  1. Neu laden und Ausmaß prüfen

    Warte ein bis zwei Minuten und lade die Seite neu. Prüfe über das Mobilnetz und auf der Statusseite Deines Hosters, ob der Ausfall alle betrifft. Notiere Uhrzeit und Adresse, an der der Fehler auftritt. Beides brauchst Du gleich für die Protokolle.

  2. Fehlerprotokoll des Servers lesen

    Im Hosting-Panel liegt meist ein Error-Log für nginx oder Apache. Suche nach Deiner notierten Uhrzeit. „upstream prematurely closed connection“ spricht für einen PHP-Absturz, „connect() to unix:“ mit „failed“ für einen gestoppten PHP-Dienst und „too big header“ für zu kleine Puffer.

  3. Datenbank sichern und Plugins abschalten

    Mit SSH-Zugang exportierst Du zuerst die Datenbank, merkst Dir die aktiven Plugins und schaltest dann alle ab. Antwortet die Seite wieder, aktivierst Du eines nach dem anderen, bis der 502 zurückkommt. Ohne SSH erreichst Du dasselbe, indem Du per FTP den Ordner wp-content/plugins umbenennst.

    Terminal (WP-CLI)
    wp db export vor-dem-test.sql
wp plugin list --status=active --field=name --skip-plugins > aktive-plugins.txt
wp plugin deactivate --all --skip-plugins --skip-themes
# danach einzeln wieder einschalten, zum Beispiel:
wp plugin activate woocommerce

  4. PHP neu starten

    Viele Hosting-Panels haben einen Knopf, der PHP neu startet. Fehlt er, stell die PHP-Version kurz um und wieder zurück, das startet die Prozesse in vielen Panels ebenfalls neu. Auf einem eigenen Server mit Debian oder Ubuntu prüfst Du den Dienst direkt. Die Versionsnummer passt Du an Deine PHP-Version an.

    Terminal (eigener Server)
    sudo systemctl status php8.3-fpm
sudo systemctl restart php8.3-fpm

  5. PHP-FPM mehr Prozesse erlauben

    Meldet das PHP-FPM-Protokoll „server reached pm.max_children setting“, reichen die Prozesse für die Last nicht. Erhöhe den Wert in der Pool-Datei behutsam, denn jeder Prozess belegt Arbeitsspeicher. Starte PHP-FPM danach neu. Auf Shared Hosting regelt das der Hoster oder ein größeres Paket.

    www.conf (PHP-FPM-Pool)
    pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

  6. nginx-Puffer für große Header vergrößern

    Steht „too big header“ im Log, vergrößerst Du die FastCGI-Puffer im server-Block Deiner Seite. Teste die Konfiguration anschließend mit nginx -t und lade nginx neu. Auf Shared Hosting kann nur der Hoster diese Werte ändern.

    nginx (server-Block)
    fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

  7. Cloudflare als Ursache ausschließen

    Pausiere Cloudflare im Dashboard der Domain für ein paar Minuten und rufe die Seite direkt auf. Läuft sie dann, vergleiche die IP-Adresse im DNS mit der Deines Servers. Frag den Hoster, ob seine Firewall Anfragen von Cloudflare blockiert. Danach schaltest Du Cloudflare wieder ein.

  8. Hoster mit Zeitpunkt und Log einschalten

    Bleibt der Fehler, gib dem Support die notierte Uhrzeit, die betroffene Adresse und die Zeilen aus dem Protokoll. Der Hoster sieht, ob PHP-FPM abstürzt, das Paket an Grenzen stößt oder eine Wartung lief. Dann kann er gezielt nachbessern.

Zuletzt geprüft am 25. September 2026.

So kommt er nicht wieder.

  • Die Last im Blick behalten: Viele Hoster zeigen CPU, Arbeitsspeicher und Prozesse im Panel. Steigen die Werte dauerhaft, rechtzeitig das Paket anpassen.
  • Einen Seiten-Cache einsetzen, damit nicht jeder Besuch einen PHP-Prozess belegt.
  • Plugins nur nach einer Sicherung aktualisieren und danach Startseite, Login und Kasse kurz aufrufen.
  • Aggressive Bots und Angriffe auf wp-login.php früh abwehren, zum Beispiel mit einer Web Application Firewall vor der Seite.

Fragen zu 502 Bad Gateway

Was bedeutet 502 Bad Gateway bei WordPress?
Ein Server in der Mitte, meist nginx oder Cloudflare, hat die Anfrage weitergereicht und von PHP keine gültige Antwort erhalten. WordPress selbst ist dabei selten beschädigt, meist hakt der PHP-Dienst dahinter.
Liegt der Fehler 502 an meinem Computer?
Fast nie. Der Fehler entsteht zwischen den Servern. Lädt die Seite auch über das Handy im Mobilnetz nicht, liegt es sicher am Server. Den Browser-Cache zu leeren schadet nicht, löst einen echten 502 aber selten.
Was ist der Unterschied zwischen 502 und 504?
Bei 502 kommt von PHP eine kaputte oder gar keine Antwort, etwa weil der Prozess abstürzt. Bei 504 lebt PHP noch, braucht aber länger, als der vorgeschaltete Server warten will. Die Lösungswege überschneiden sich deshalb nur teilweise.
Verschwindet ein 502 von allein?
Kurze 502-Fehler nach einem Neustart oder einer Lastspitze gehen oft nach wenigen Minuten weg. Kommt der Fehler täglich oder bei bestimmten Aktionen, steckt eine feste Ursache dahinter, die Du mit den Schritten oben findest.

Verwandte Fehler

Alle WordPress-Fehler

Lieber eine Website, die einfach läuft?

Wir bauen Websites, die schnell laden und ohne Update-Stress laufen. Oder wir übernehmen Deine WordPress-Seite samt Pflege. Erst Dein Paket, dann ein Termin per Video.

Kevin Baum im Videocall an seinem Schreibtisch, im Hintergrund eine Holzlattenwand mit farbigem Licht.

Erst Dein Paket, dann der Termin

Im Preisrechner tippst Du an, was Dich bremst. Du siehst sofort Dein Paket mit Preisspanne. Danach wählst Du direkt einen Termin, das Gespräch läuft per Video.

Dein Preis in 2 Minuten