502 Bad Gateway bedeutet: Ein Server, der deine Anfrage weiterreichen sollte, hat von der nächsten Station eine ungültige oder gar keine Antwort bekommen. Bei WordPress-Hosting sind fast immer zwei Ketten im Spiel: Webserver → PHP-FPM oder CDN/Proxy → Webserver. Der Fehler sitzt an einem dieser Übergänge.
Wie die Kette aussieht
Moderne Hosting-Umgebungen verarbeiten eine Anfrage in Stationen: Ein Proxy oder CDN (z. B. Cloudflare) nimmt sie an, reicht sie an den Webserver (Nginx/Apache) weiter, der übergibt an PHP-FPM, das WordPress ausführt. Stürzt PHP ab, braucht es zu lang oder antwortet mit Unsinn, meldet die Station davor: Bad Gateway. Das unterscheidet den 502 vom 500-Fehler — dort antwortet PHP, aber mit einem Fehler; beim 502 antwortet es gar nicht sauber.
Schritt für Schritt eingrenzen
- Erstmal: Ist es vorübergehend? Ein einzelner 502 nach einem Deployment oder Update ist oft nur ein neustartender PHP-Prozess. Warte 30 Sekunden und lade neu (Strg+Shift+R, um den Cache zu umgehen).
- CDN testweise umgehen: Läuft die Seite hinter Cloudflare, aktiviere den Development Mode oder rufe die Seite direkt über die Server-IP auf (Hosts-Datei-Eintrag). Funktioniert sie direkt, liegt das Problem zwischen CDN und Server — häufig der SSL-Modus („Full (strict)“ statt „Flexible“) oder eine veraltete Server-IP im DNS.
- PHP-FPM-Absturz: Im Hosting-Panel (oder per SSH mit
systemctl status php8.2-fpm) prüfen, ob PHP läuft. Bei Managed Hosting: Der Support sieht in den FPM-Logs sofort, ob Prozesse wegen Speichermangel (OOM) beendet wurden. - Ressourcen-Fresser finden: Ein 502 unter Last deutet auf zu wenige PHP-Worker oder ein Plugin, das Prozesse blockiert (externe API-Aufrufe ohne Timeout, endlose Schleifen in WP-Cron). Deaktiviere testweise die Plugins per FTP (
plugins→plugins_alt) — lädt die Seite, engst du den Verursacher durch einzelnes Reaktivieren ein. Auch hängende WP-Cron-Aufgaben sind ein Klassiker. - Timeouts abgleichen: Braucht ein legitimer Vorgang (Import, Backup) länger als der Proxy erlaubt, bricht die Kette. Die Werte
proxy_read_timeout(Nginx) bzw. FastCGI-Timeout müssen zur maximalen PHP-Laufzeit (max_execution_time) passen — das stellt der Hoster ein.
Was du als Website-Betreiber selbst tun kannst
- Schwere Vorgänge entzerren: Importe, Bildoptimierungen und Backups nicht zur Hauptbesuchszeit laufen lassen.
- Caching einsetzen: Ein Page Cache beantwortet die meisten Anfragen, ohne PHP überhaupt zu bemühen — die FPM-Worker bleiben frei für echte Arbeit. Mehr dazu im Artikel WordPress beschleunigen.
- Plugins ausmisten: Jedes Plugin, das bei jedem Seitenaufruf externe Dienste anfragt, ist ein 502-Kandidat, sobald dieser Dienst lahmt.
Wann der Hoster ran muss
Alles, was FPM-Worker-Anzahl, Timeouts und Proxy-Konfiguration betrifft, liegt beim Hoster. Melde dich mit konkreten Fakten: genaue Uhrzeit des Fehlers, betroffene URL, ob der Fehler unter Last oder dauerhaft auftritt. Bei wiederkehrenden 502ern trotz sauberer Website ist die ehrliche Antwort oft: Das Hosting-Paket ist zu klein für die Website.
Ammera Care erkennt Ausfälle wie diesen im Minutentakt und unterscheidet automatisch zwischen einem einmaligen Schluckauf und einem echten Ausfall. Bei Shops prüft das Commerce-Modul zusätzlich stündlich, ob Warenkorb und Kasse wirklich funktionieren — denn ein 502 an der Kasse kostet bares Geld. Module ansehen.
