504-Fehler in WordPress: Hosting oder Website?

#Was bedeutet der Fehler 504 in WordPress

MDN, unter Verweis auf RFC 9110, definiert 504 als Situation, in der ein Server, der als Gateway oder Proxy arbeitet, “keine rechtzeitige Antwort vom Upstream-Server erhalten hat” (eigene Übersetzung). Das unterscheidet sich von 502 Bad Gateway: Dort kam eine Antwort, aber sie war ungültig. Bei 504 kam nichts.

Bei typischem WordPress-Hosting sieht die Kette so aus: Browser, optional ein CDN, nginx, PHP-FPM, Datenbank und eventuell ein Objekt-Cache. Den Code 504 erzeugt das Glied, das gewartet hat. Schon das zeigt, wo Sie suchen müssen. Wartet nginx auf PHP, liegt das Problem in PHP, in der Datenbank oder in der Warteschlange vor PHP. Wartet das CDN, liegt es am Ursprungsserver.

Die MDN-Dokumentation merkt außerdem an, dass es viele Ursachen gibt und die Behebung in der Regel eine Analyse auf Seiten des Server-Administrators erfordert. Deshalb gibt es im Folgenden keinen magischen Fix, sondern eine Reihenfolge von Prüfungen.

#Ist der 504 ein Problem des Hostings oder der Website

Die Frage entscheidet sich am Umfang des Fehlers. Die folgende Tabelle ist eine Entscheidungshilfe, kein Urteil.

Die Verantwortung des Hostings beginnt dort, wo die Limits (Anzahl der Worker, Speicher, CPU) für den normalen Traffic der Website zu klein sind. Die Verantwortung der Website beginnt dort, wo eine einzelne Anfrage so viel Arbeit macht, dass sie einen Worker für Dutzende Sekunden blockiert. In der Praxis wirken oft beide zugleich: Langsame Anfragen belegen Worker, und ein kleiner Pool hat keine Reserve.

#Warum fällt meine WordPress-Website alle paar Wochen aus

Im November 2025 fragte im Forum r/webdev der Inhaber von zwei WordPress-Websites, die derselbe Entwickler betreut, ganz direkt, ob das normal sei:

Alle paar Wochen fallen die Websites plötzlich aus oder etwas geht kaputt: Entweder lädt die Seite nicht, oder irgendetwas funktioniert nicht mehr. Der Entwickler sagt jedes Mal, es sei ein Problem mit dem Hosting oder man müsse etwas verlängern, sichern oder aktualisieren, und bietet dann gegen Aufpreis einen Jahresvertrag für Wartung oder Backups an.

(eigene Übersetzung, r/webdev, Thread vom 2. November 2025)

Der Thread bekam Dutzende Antworten. Hier die Fragen, die sich daraus ergeben, und was Sie selbst prüfen können.

#Liegt es am Hosting oder am Entwickler

Die Antworten im Thread teilen sich in zwei Lager. Ein Entwickler, der die Websites aller seiner Kunden überwacht, schreibt, dass Websites bei günstigeren Hostern “mindestens einmal pro Woche ausfallen”, weil sie dem Bot-Traffic nicht standhalten (eigene Übersetzung, tomhermans, r/webdev). Ein anderer hält dagegen, eine richtig konfigurierte Website bei gutem Hosting sollte “praktisch NIE ausfallen” (eigene Übersetzung, redlotusaustin, r/webdev).

Beides kann gleichzeitig stimmen, und die Tabelle oben hilft, es auseinanderzuhalten. Zeigt jeder Ausfall einen 502 oder 504 auf der ganzen Website, liegt es meist an den Ressourcen: ein zu kleiner PHP-FPM-Pool oder ein überlasteter Shared-Server. Geht die Website an einer Stelle kaputt, während der Rest läuft, steckt die Ursache im Code, in einem Plugin oder im Theme.

#Können Bots eine WordPress-Website auf günstigem Hosting lahmlegen

Ja. Ein Bot, der ungecachte Adressen abruft, startet bei jeder Anfrage PHP. Auf Shared Hosting mit wenigen PHP-Workern ist die Warteschlange schnell voll, und weitere Anfragen enden mit dem Fehler 504, den die Abschnitte unten beschreiben. Abhilfe schaffen ein Seiten-Cache vor PHP (auf dem Server oder im CDN) und ein Limit für Anfragen von einem einzelnen Client. Wenn Sie Bots in Cloudflare blockieren, achten Sie auf die Option, die auch den Googlebot aussperrt. Das beschreiben wir im Beitrag blockiert Cloudflare den Googlebot.

#Machen Plugin-Updates die WordPress-Website kaputt

Ein Teilnehmer im Thread nennt Plugin-Updates als häufigen Grund für Ausfälle, wenn sie direkt auf der laufenden Website eingespielt werden, ohne Test auf einer Staging-Umgebung (eigene Übersetzung, technomalist, r/webdev). Fallen die Ausfälle zeitlich mit Updates zusammen, vergleichen Sie die Ausfalldaten mit dem Update-Verlauf. Wie die Arbeit mit einer Testkopie aussieht, zeigt unsere Anleitung zu WordPress-Staging.

#Können wiederholte Ausfälle auf einen Hack hindeuten

Ja. Im Thread wird ein typischer Kreislauf beschrieben: Eine über ein anfälliges Plugin infizierte Website wird aus einem Backup wiederhergestellt, die Lücke bleibt aber offen, und nach ein paar Tagen wiederholt sich alles (eigene Übersetzung, 30thnight, r/webdev). Ein Backup einzuspielen, ohne die Ursache zu beseitigen, löst das Problem nicht. Die Schritte zur Bereinigung stehen in unserer Anleitung zum Entfernen von Malware aus WordPress.

#Wie finde ich selbst heraus, warum die WordPress-Website ausgefallen ist

Die kürzeste Antwort im Thread lautet: “Was sagen Ihre Logs?” (eigene Übersetzung, chmod777, r/webdev). Das können Sie als Inhaber ohne Entwickler erledigen:

1. Schalten Sie ein externes Monitoring der Erreichbarkeit ein, das Uhrzeit und Dauer jedes Ausfalls festhält.
2. Sorgen Sie für einen eigenen Zugang zum Hosting-Panel, nicht nur zum WordPress-Dashboard.
3. Öffnen Sie nach einem Ausfall das PHP-Fehlerlog und das Fehlerlog des Webservers zur selben Uhrzeit. Fatale PHP-Fehler deuten auf Code oder ein Plugin, überschrittene Prozesslimits und Timeouts auf die Ressourcen des Hostings.
4. Vergleichen Sie die Ausfallzeiten mit den Update-Daten von Plugins, Theme und WordPress.

#Lohnt sich ein kostenpflichtiger Wartungsvertrag für WordPress

Ein Wartungsvertrag bezahlt regelmäßige Arbeit: vor dem Einspielen getestete Updates, Monitoring, Backups und die Reaktion auf Ausfälle. Er sollte aber keine Antwort auf Ausfälle sein, deren Ursache niemand benannt hat. Ein Ausfall alle paar Wochen ist nicht normal, weder mit noch ohne Vertrag. Nach jedem Ausfall sollten Sie schriftlich bekommen, was die Ursache war und was geändert wurde, damit er sich nicht wiederholt. So arbeiten wir bei der Wartung von WordPress-Websites.

#Wie finden Sie heraus, wo die Anfrage hängen bleibt

Beginnen Sie an drei Stellen, in dieser Reihenfolge.

1. Fehlerlog des Webservers aus der Stunde des Ausfalls. In nginx bestätigt der Eintrag upstream timed out, dass der Server auf PHP gewartet hat.
2. PHP-FPM-Log. Eine Meldung über das Erreichen von pm.max_children bedeutet, dass der Pool voll war und weitere Anfragen in der Schlange standen. Die Option pm.max_children legt, wie die PHP-Dokumentation beschreibt, das Limit gleichzeitiger Anfragen fest, die der Pool bearbeitet.
3. WordPress-Log. Setzen Sie in der wp-config.php WP_DEBUG auf true, WP_DEBUG_LOG auf true und WP_DEBUG_DISPLAY auf false. Die Fehler landen dann in wp-content/debug.log statt auf dem Bildschirm. So beschreibt es die WordPress-Dokumentation. Schalten Sie das Debugging nach der Diagnose wieder aus.

Bietet das Hosting Zugriff auf das Slowlog von PHP-FPM, setzen Sie request_slowlog_timeout, und PHP schreibt den Backtrace von Anfragen, die länger als das Limit dauern. Standardmäßig ist die Option deaktiviert (Wert 0). Der Backtrace zeigt, in welcher Funktion eines Plugins oder Themes PHP gewartet hat.

Bei Shared Hosting fehlt der Zugriff auf diese Logs oft. Dann ist der Zugang zu ihnen und zu den Metriken des PHP-Pools das Erste, worum Sie den Support bitten müssen, zusammen mit der Uhrzeit des Ausfalls und der Adresse, die den 504 geliefert hat.

#Warum führt ein zu kleiner PHP-FPM-Pool zu 504

Jede dynamische Anfrage belegt einen PHP-FPM-Worker bis zum Ende der Antwort. Sind alle Worker beschäftigt, warten neue Anfragen. Warten sie länger als das Limit des Proxys, sieht der Besucher einen 504.

Der Standardwert von fastcgi_read_timeout in nginx beträgt 60 Sekunden, und die nginx-Dokumentation merkt an, dass das Limit zwischen zwei aufeinanderfolgenden Lesevorgängen vom FastCGI-Server gilt, nicht für die gesamte Antwort. Bei Managed Hosting ist der Wert mitunter ein anderer, gehen Sie also nicht davon aus, dass er bei Ihnen genau 60 Sekunden beträgt.

Ein höherer pm.max_children hilft nur, wenn der Server dafür den Speicher hat. Jeder WordPress-Worker mit einigen Plugins belegt davon einen spürbaren Teil, ein zu hoher Wert endet daher in erschöpftem RAM und beendeten Prozessen, also in einem schlechteren Zustand als eine Warteschlange. Die Pool-Konfiguration ist Aufgabe eines Administrators, der den Speicherverbrauch sieht.

#Wie verursachen langsame Abfragen und autoloadete Optionen einen 504

Betrifft der 504 die ganze Website und ist der Pool nicht durch Traffic voll, prüfen Sie die Datenbank. Die WordPress-Dokumentation weist darauf hin, dass WordPress bei jeder Anfrage viele Abfragen wiederholt und als autoload markierte Optionen bei jedem Aufruf geladen werden. Sie empfiehlt, sie unter 800 KB zu halten, und die vollständigen Empfehlungen stehen im Optimierungsleitfaden. Ein Plugin, das große Datenmengen mit Autoload in wp_options ablegt, schiebt sie in jede Anfrage. Die Größe des Autoloads prüfen Sie mit einer SQL-Abfrage über die Spalte autoload in der Options-Tabelle.

Zum Aufspüren langsamer Abfragen dient die Konstante SAVEQUERIES. Sie speichert jede Abfrage, ihre Ausführungszeit und die aufrufende Funktion in $wpdb->queries. Sie kostet Leistung, schalten Sie sie also nur kurz und nach Möglichkeit auf einer Staging-Umgebung ein.

#Wann verursachen Objekt-Cache und Redis einen 504

Ein persistenter Objekt-Cache verringert die Zahl der Datenbankabfragen und beschleunigt die Website in der Regel. Er braucht jedoch einen laufenden Cache-Server und die Drop-in-Datei wp-content/object-cache.php.

Der Ausfall wirkt in die andere Richtung, wenn diese Datei existiert, der Redis-Server aber nicht antwortet. Jede Anfrage versucht dann, sich mit dem Cache zu verbinden, wartet auf das Verbindungs-Timeout und macht erst danach weiter oder gibt auf. Das Symptom ist ein 504 direkt nach einem Neustart oder Ausfall des Cache-Dienstes auf Seiten des Hostings, obwohl sich der Code der Website nicht geändert hat.

Der Test ist einfach: Benennen Sie object-cache.php um. Verschwindet der 504, ist der Cache schuld und nicht WordPress. Stellen Sie die Datei erst nach der Reparatur des Dienstes wieder her.

#Wie lösen WP-Cron, admin-ajax und externe APIs einen 504 aus

Drei Quellen einzelner, langsamer Anfragen sollten Sie getrennt prüfen.

• WP-Cron. Die WordPress-Dokumentation erklärt, dass WP-Cron beim Seitenaufruf startet und nicht als dauerhafter Prozess läuft. Überfällige, aufwendige Aufgaben (Backups, Importe, Versand) können daher eine gewöhnliche Besucheranfrage belasten. Die Umstellung der Aufrufe auf den System-Cron des Hostings entlastet das Frontend.
• admin-ajax.php. Plugins senden hierhin Anfragen aus dem Dashboard und aus dem Frontend. Tritt der 504 genau hier auf, suchen Sie das Plugin, das im Hintergrund einen aufwendigen Vorgang ausführt.
• Externe APIs. Ein Plugin, das auf ein langsames externes System (Zahlung, ERP, Versand) wartet, hält den Worker so lange, wie dieses System antwortet. Fehlt in diesem Plugin ein eigenes, kurzes Timeout, wird der Ausfall eines Fremden zu Ihrem 504.

#Worin unterscheidet sich 504 von 502 und 524

• 502 Bad Gateway: Der Server hinter dem Proxy hat geantwortet, aber die Antwort war ungültig. Oft ist ein PHP-FPM-Prozess abgestürzt.
• 504 Gateway Timeout: keine Antwort innerhalb der Zeit. Meist Überlastung oder eine langsame Anfrage.
• 524: ein Cloudflare-Code. Die Cloudflare-Dokumentation nennt ihn für den Fall, dass der Ursprungsserver nicht innerhalb der standardmäßigen 125 Sekunden antwortet. Cloudflare rät, das Hosting lange Prozesse und Überlastung prüfen zu lassen und große Vorgänge über einen Kanal ohne Proxy zu leiten.

Hinter einem CDN können Sie daher für dieselbe Ursache zwei verschiedene Codes sehen, je nachdem, welchem Glied zuerst die Geduld ausging.

#Wann sollten Sie das Timeout erhöhen und wann nicht

Die Erhöhung von fastcgi_read_timeout oder des PHP-Zeitlimits ist für einen einzelnen, bewusst langen Vorgang gerechtfertigt, etwa einen manuellen Import. Bei einer Website, die Besuchern einen 504 anzeigt, ist es Verschleierung: Die langsame Anfrage belegt weiterhin einen Worker, nur länger, und der Pool füllt sich schneller.

PHP-FPM hat eine eigene Sicherung, request_terminate_timeout. Die Dokumentation beschreibt sie als Limit, nach dem der Prozess, der die Anfrage bearbeitet, beendet wird, und nennt den Standardwert 0, also deaktiviert. Vernünftig gesetzt, schützt sie den Pool vor einem einzelnen hängenden Skript.

Aktualisierung vom 27. Oktober 2026. Lange Aufgaben in wp-admin wie eine Datensicherung oder ein Datenbankexport sind auf Shared Hosting ein klassischer Auslöser für einen 504. Das Limit des Proxys können Sie dort meist nicht ändern, und der Proxy beendet die Anfrage, bevor PHP fertig ist, egal was in max_execution_time steht. Abhilfe schafft eine Aufteilung der Aufgabe in kurze Anfragen, die sich fortsetzen lassen. Unser Plugin Migrator zeigt das Muster. Seit Version 1.6.0 exportiert eine in wp-admin gestartete Sicherung die Datenbank in Schritten, pro Anfrage einen Teil der Zeilen, sodass auch eine große Datenbank auf Shared Hosting ohne 504 Gateway Timeout exportiert wird. Ein unterbrochener Schritt setzt dort an, wo der letzte aufgehört hat, und der Filter migrator_step_seconds legt fest, wie lange ein Schritt arbeiten darf, für Hoster, deren Proxy Anfragen früh abbricht. Bricht der Export oder Import eines Plugins jedes Mal an ähnlicher Stelle mit 504 ab, suchen Sie nach einem Modus, der in Portionen arbeitet und fortsetzen kann, oder nach WP-CLI-Befehlen (Migrator hat seit Version 1.5.0 Befehle unter wp migrator). Höhere PHP-Limits helfen hier nicht, weil der Proxy sie nicht beachtet.

#Welche nginx-Timeouts zu einem 504 führen

Das FastCGI-Modul von nginx hat drei getrennte Zeitgeber, und laut der Dokumentation von ngx_http_fastcgi_module steht jeder standardmäßig auf 60 Sekunden.

Die beiden letzten Zeitgeber beginnen bei jedem Datenpaket von vorn. Ein Skript, das zwischendurch etwas ausgibt, kann daher länger als eine Minute laufen, ohne dass ein Fehler entsteht. Ein Skript, das schweigt, weil es auf die Datenbank oder eine externe API wartet, bekommt nach 60 Sekunden einen 504. fastcgi_send_timeout spielt vor allem bei großen POST-Anfragen eine Rolle, etwa beim Hochladen einer Datei oder bei einem Import.

Steht nginx vor Apache statt direkt vor PHP-FPM, zählt proxy_read_timeout aus dem Modul ngx_http_proxy_module. Auch dieser Wert liegt bei 60 Sekunden und misst ebenfalls die Pause zwischen zwei Lesevorgängen, nicht die gesamte Antwort.

Alle diese Direktiven gelten in den Kontexten http, server und location. Ein höheres Limit lässt sich also auf den einen Pfad beschränken, der es wirklich braucht, statt es für den ganzen Server zu setzen:

location = /wp-admin/admin-ajax.php {
    # höheres Limit nur hier, der Rest des Servers bleibt bei 60 s
    fastcgi_read_timeout 120s;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Der Pfad zum PHP-FPM-Socket unterscheidet sich je nach Distribution und Hoster. Übernehmen Sie ihn aus Ihrer bestehenden Konfiguration, nicht aus dem Beispiel.

#Timeout in Apache mit PHP-FPM und mod_proxy_fcgi

Apache übergibt PHP über mod_proxy_fcgi an PHP-FPM, meist mit SetHandler "proxy:unix:/pfad/zum/socket.sock|fcgi://localhost/". Die Wartezeit bestimmen hier drei Einstellungen, die ihren Standardwert jeweils von der nächsten erben:

• Timeout aus dem Apache-Kern, standardmäßig 60 Sekunden. Die Apache-Dokumentation nennt ihn den Standardwert in mod_proxy, solange ProxyTimeout nicht gesetzt ist.
• ProxyTimeout aus mod_proxy, standardmäßig gleich Timeout. Die Dokumentation beschreibt ihn als Möglichkeit, bei einem hängenden Anwendungsserver einen Timeout zurückzugeben, statt beliebig lange zu warten.
• der Parameter timeout bei ProxyPass oder in einer Worker-Definition, standardmäßig gleich ProxyTimeout. Er gibt an, wie viele Sekunden Apache auf Daten an das oder vom Backend wartet.

Alle drei haben den Kontext server config und virtual host und wirken deshalb nicht in der .htaccess. Auf Shared Hosting kann sie nur der Serveradministrator ändern.

#Warum max_execution_time nicht vor einem 504 schützt

max_execution_time steht in PHP standardmäßig auf 30 Sekunden, also unter den 60 Sekunden von nginx. Man könnte meinen, PHP bricht ein Skript immer ab, bevor der Proxy einen 504 liefert. Das stimmt nicht. Die PHP-Dokumentation hält fest, dass Systemaufrufe und Stream-Operationen auf anderen Systemen als Windows nicht in dieses Limit eingehen. Die Seite zu set_time_limit() ergänzt, dass auch Datenbankabfragen nicht mitgezählt werden.

In der Praxis erreicht eine WordPress-Anfrage, die 70 Sekunden auf eine gesperrte MySQL-Tabelle oder auf ein Zahlungsgateway wartet, das PHP-Limit nie. Der Worker bleibt belegt, und nginx liefert nach 60 Sekunden Stille einen 504. Ausnahme sind PHP-Builds mit --enable-zend-max-execution-timers (Standard für ZTS-Builds seit PHP 8.3.0): Dort misst das Limit die verstrichene Zeit, Warten auf Ein- und Ausgabe eingeschlossen.

Bei externen APIs kommt es deshalb auf das Timeout der Verbindung selbst an. Die HTTP-Funktionen von WordPress (WP_Http::request) haben einen Standard-timeout von 5 Sekunden, der sich über den Filter http_request_timeout ändern lässt. Ein Plugin, das diesen Wert auf eine Minute anhebt, entfernt die Absicherung, und genau dieses Plugin macht aus einer langsamen API einen 504.

Aus diesen Zahlen ergibt sich eine Reihenfolge, die die Diagnose erleichtert: Jedes innere Limit ist kürzer als das äußere. Das HTTP-Timeout im Plugin (5 s) unter dem PHP-Limit (30 s), dieses unter fastcgi_read_timeout (60 s) und dieses unter den 125 Sekunden von Cloudflare. Greift das innere Limit zuerst, landet der Fehler in der debug.log, mit dem Namen der Funktion, die gewartet hat. Greift das äußere zuerst, bleibt nur eine allgemeine 504-Seite ohne Spur in den WordPress-Logs.

#Wie Sie die Statusseite von PHP-FPM lesen

Den schnellsten Beleg dafür, ob ein 504 aus einer Warteschlange oder aus einer einzelnen langsamen Anfrage stammt, liefert die Statusseite von PHP-FPM. Sie wird über die Option pm.status_path in der Pool-Konfiguration aktiviert, die standardmäßig nicht gesetzt ist. Die PHP-Dokumentation warnt, dass die Seite Anfrage-URLs und Angaben zu den Ressourcen offenlegt. Beschränken Sie sie daher auf interne Anfragen oder bekannte IP-Adressen. Der Parameter ?json liefert JSON, ?full ergänzt Details zu jedem Prozess.

Während einer Störung ist die Auswertung einfach. Eine Warteschlange über null und keine freien Prozesse bedeuten einen vollen Pool: zu wenige Worker oder zu langsame Anfragen, die sie blockieren. Eine leere Warteschlange und freie Prozesse bei gleichzeitigem 504 bedeuten, dass die Zeit in der Anfrage selbst verloren geht, also in der Datenbank, im Cache oder bei einer externen API. Die Obergrenze der Warteschlange setzt listen.backlog, laut FPM-Konfigurationsreferenz unter Linux standardmäßig 511.

#Wie beheben Sie einen 504 Schritt für Schritt

1. Umfang bestimmen: ganze Website, eine Adresse oder nur wp-admin.
2. Die Logs des Servers und von PHP-FPM aus der Stunde des Ausfalls lesen.
3. debug.log aktivieren und den Fehler reproduzieren.
4. Plugins deaktivieren (per WP-CLI oder durch Umbenennen des Ordners), dann einzeln wieder aktivieren und die Antwortzeit messen.
5. Existiert object-cache.php, sie probeweise abschalten.
6. Autoloadete Optionen und überfällige WP-Cron-Aufgaben prüfen.
7. Erst zuletzt eine Vergrößerung des Pools oder der Timeouts erwägen, gemeinsam mit dem Hosting-Administrator.

Trat der 504 direkt nach einem Update auf, lesen Sie auch die Anleitung zur Wiederherstellung von WordPress nach einem fehlgeschlagenen Update.

#Wann ist das ein Fall für einen Spezialisten

Wenn die Logs auf den PHP-FPM-Pool zeigen, das Hosting aber keinen Zugriff auf dessen Konfiguration gibt. Wenn der 504 nach jeder Reparatur wiederkehrt. Wenn ein Shop während des Ausfalls Bestellungen verliert. Bei einem Audit, der die Kosten des Hostings von den Kosten des Codes trennen soll, hilft die Performance-Optimierung Ihrer WordPress-Website. Liegt die Website gerade lahm und ist die Ursache unbekannt, ist der WordPress-Reparatur-Service mit technischem Support die Rettung.