Ein 504 Gateway Timeout bedeutet, dass der Server vor PHP (nginx, ein CDN oder der Proxy des Hosters) innerhalb der vorgesehenen Zeit keine Antwort erhalten hat. WordPress ist dabei meist nicht der Verursacher, sondern das Opfer: Die Anfrage wartet in der Schlange auf einen freien PHP-Worker oder dauert selbst zu lange. Beginnen Sie mit den PHP-FPM-Logs aus der Stunde des Ausfalls und prüfen Sie dann, ob der Fehler die ganze Website oder nur eine Adresse betrifft.
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, “did not get a response in time from the upstream server”. 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.
| Symptom | Wahrscheinlichste Richtung |
|---|---|
| 504 auf der ganzen Website, auch auf einfachen Unterseiten | Zu wenige PHP-Worker oder überlasteter Server: Hosting oder Traffic |
| 504 nur unter einer Adresse | Langsame Abfrage, Plugin oder externe API, die von dieser Adresse aufgerufen wird |
| 504 in wp-admin und beim Speichern, Frontend läuft aus dem Cache | Aufwendige Anfragen angemeldeter Nutzer, die den Cache umgehen |
| 504 sporadisch, immer zu denselben Zeiten | Zeitgesteuerte Aufgaben, Backups oder Traffic-Spitzen |
| 504 nach einem Plugin-Wechsel oder Update | Plugin-Konflikt oder eine Datenbankmigration, die zu lange dauert |
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.
Wie finden Sie heraus, wo die Anfrage hängen bleibt?
Beginnen Sie an drei Stellen, in dieser Reihenfolge.
- Fehlerlog des Webservers aus der Stunde des Ausfalls. In nginx bestätigt der Eintrag
upstream timed out, dass der Server auf PHP gewartet hat. - PHP-FPM-Log. Eine Meldung über das Erreichen von
pm.max_childrenbedeutet, dass der Pool voll war und weitere Anfragen in der Schlange standen. Die Optionpm.max_childrenlegt, wie die PHP-Dokumentation beschreibt, das Limit gleichzeitiger Anfragen fest, die der Pool bearbeitet. - WordPress-Log. Setzen Sie in der
wp-config.phpWP_DEBUGauftrue,WP_DEBUG_LOGauftrueundWP_DEBUG_DISPLAYauffalse. Die Fehler landen dann inwp-content/debug.logstatt 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.
Wie beheben Sie einen 504 Schritt für Schritt?
- Umfang bestimmen: ganze Website, eine Adresse oder nur wp-admin.
- Die Logs des Servers und von PHP-FPM aus der Stunde des Ausfalls lesen.
debug.logaktivieren und den Fehler reproduzieren.- Plugins deaktivieren (per WP-CLI oder durch Umbenennen des Ordners), dann einzeln wieder aktivieren und die Antwortzeit messen.
- Existiert
object-cache.php, sie probeweise abschalten. - Autoloadete Optionen und überfällige WP-Cron-Aufgaben prüfen.
- 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.
