Dein Preis in 2 Minuten

WordPress-Fehler504

WordPress 504 Gateway Timeout: wenn PHP zu lange braucht

Ein 504 Gateway Timeout bedeutet: Der vorgeschaltete Server, meist nginx, ein Proxy oder Cloudflare, hat auf die Antwort von PHP gewartet und irgendwann aufgegeben. WordPress arbeitet also noch, ist aber zu langsam. Typische Auslöser sind lange Importe oder Sicherungen, langsame Datenbankabfragen und Plugins, die auf einen externen Dienst warten. Auch ein überlastetes Hosting-Paket kommt infrage. Suche die langsame Stelle im Protokoll, teile große Aufgaben auf und hebe Zeitlimits erst als letzten Schritt an.

So sieht die Meldung aus

  • 504 Gateway Time-out
  • 504 Gateway Timeout
  • The gateway did not receive a timely response from the upstream server or application.
  • Error code 504
  • HTTP ERROR 504

Woran es liegt.

Lange Aufgaben in einer einzigen Anfrage

Importe, Exporte, Sicherungen, Bildoptimierung oder große Updates laufen oft in einem einzigen Seitenaufruf. Dauert das länger als das Zeitlimit von nginx oder Proxy, bricht die Verbindung ab, obwohl PHP weiterrechnet.

Langsame Datenbank

Große Tabellen mit Protokollen, viele abgelaufene Transients oder eine aufgeblähte wp_options mit viel Autoload bremsen jede Abfrage. Besonders Shops und ältere Seiten sammeln über die Jahre viel Ballast an.

Plugin wartet auf einen externen Dienst

Plugins für Lizenzprüfung, Newsletter, Zahlungen oder Social Media fragen bei fremden Servern nach. Antwortet der Dienst nicht, hängt PHP fest, bis dessen Zeitlimit greift. Der Proxy gibt oft schon vorher auf.

Zu wenige Ressourcen

Sind alle PHP-Prozesse belegt, warten neue Anfragen in einer Schlange. Bei Besucherspitzen oder Bot-Wellen dauert das so lange, dass der vorgeschaltete Server seine Wartezeit überschreitet.

Knappe Zeitlimits

nginx wartet in der Grundeinstellung 60 Sekunden auf PHP, festgelegt über fastcgi_read_timeout. Manche Hoster setzen engere Werte. Für normale Seitenaufrufe reicht das locker, für Importe im Browser oft nicht.

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. Muster erkennen

    Notiere, wann der 504 auftritt: bei jedem Aufruf, nur im Dashboard oder nur bei einer bestimmten Aktion wie Import, Speichern oder Update. Tritt er nur bei einer Aktion auf, kennst Du den Auslöser schon fast. Betrifft er die ganze Seite, liegt es eher am Server oder an einem Plugin.

  2. Server-Log auf Zeitüberschreitungen prüfen

    Im Fehlerprotokoll von nginx steht bei diesem Fehler „upstream timed out (110: Connection timed out) while reading response header from upstream“. Die Zeile nennt auch die aufgerufene Adresse. Ist es immer dieselbe, etwa admin-ajax.php oder ein bestimmter REST-Endpunkt, grenzt das die Suche stark ein.

  3. Langsame Abfragen mit Query Monitor finden

    Lege vorab eine Sicherung von Dateien und Datenbank an. Installiere dann das Plugin Query Monitor und rufe eine langsame Seite auf, die gerade noch lädt. Es zeigt, welche Datenbankabfragen und externen HTTP-Aufrufe am längsten dauern und aus welchem Plugin sie stammen. Entferne Query Monitor nach der Suche wieder.

  4. Plugins gezielt ausschließen

    Hast Du einen Verdacht, schalte genau dieses Plugin unter Plugins → Installierte Plugins ab und wiederhole die Aktion. Ohne Verdacht deaktivierst Du per WP-CLI alle Plugins auf einen Schlag und aktivierst sie danach nacheinander, bis der Timeout zurückkehrt.

    Terminal (WP-CLI)
    wp plugin list --status=active --field=name > aktiv.txt
wp plugin deactivate --all
# nach dem Test alle wieder einschalten:
wp plugin activate $(cat aktiv.txt)

  5. Große Aufgaben über WP-CLI oder in Etappen

    Über SSH laufen Updates, Exporte und Suchen-Ersetzen ohne das Zeitlimit des Webservers, weil kein Proxy dazwischen sitzt. Teile große CSV-Importe in kleinere Dateien. Stelle Sicherungs-Plugins so ein, dass sie in mehreren Schritten oder nachts arbeiten.

    Terminal (WP-CLI)
    wp core update
wp plugin update --all
wp db export sicherung.sql

  6. Datenbank entschlacken

    Lösche abgelaufene Transients mit wp transient delete --expired und prüfe, welche Einträge in wp_options bei jedem Aufruf geladen werden. Sehr große Einträge stammen oft von Plugins, die längst entfernt sind. Sichere vorher die Datenbank. Das Präfix wp_ ersetzt Du durch Dein eigenes, falls es abweicht.

    phpMyAdmin (SQL)
    SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bytes DESC
LIMIT 20;

  7. Zeitlimits anheben (eigener Server)

    Brauchst Du dauerhaft längere Laufzeiten, müssen nginx und PHP zusammenpassen: fastcgi_read_timeout im server-Block, max_execution_time in der php.ini und request_terminate_timeout im PHP-FPM-Pool, falls gesetzt. Das behandelt nur das Symptom. Die langsame Stelle bleibt bestehen.

    nginx und php.ini
    # nginx, im location-Block für PHP
fastcgi_read_timeout 300s;

# php.ini
max_execution_time = 300

  8. Hoster und Cloudflare einbeziehen

    Auf Shared Hosting legt der Hoster die Zeitlimits fest. Schick ihm Uhrzeit, Adresse und die Zeile aus dem Log. Nutzt Du Cloudflare, bricht die Verbindung dort nach einer festen Wartezeit ab, das zeigt Cloudflare meist als eigenen Fehler 524. Lange Aufgaben gehören dann in WP-CLI oder einen Cronjob.

Zuletzt geprüft am 25. September 2026.

So kommt er nicht wieder.

  • Importe, Sicherungen und Bildoptimierung in kleine Pakete teilen oder nachts per Cronjob laufen lassen.
  • Die Datenbank regelmäßig von alten Revisionen, Protokollen und abgelaufenen Transients befreien.
  • Plugins meiden, die bei jedem Seitenaufruf fremde Server abfragen.
  • Einen Objekt-Cache wie Redis nutzen, wenn der Hoster ihn anbietet. Er entlastet die Datenbank spürbar.

Fragen zu 504 Gateway Timeout

Was heißt 504 Gateway Timeout bei WordPress?
Ein vorgeschalteter Server hat zu lange auf PHP gewartet und die Anfrage abgebrochen. WordPress lief dabei oft noch weiter. Der Fehler zeigt also eine zu langsame Stelle an, keinen kaputten Code.
Läuft ein Import nach dem 504 im Hintergrund weiter?
Manchmal ja. PHP rechnet oft weiter, bis sein eigenes Zeitlimit greift, auch wenn der Browser schon den Fehler zeigt. Starte den Import deshalb nicht sofort neu, sondern prüfe erst, was schon angekommen ist. Sonst entstehen doppelte Einträge.
Hilft es, max_execution_time zu erhöhen?
Nur zusammen mit dem Zeitlimit von nginx oder Proxy, denn dieses greift zuerst. Auf Shared Hosting ändert beide Werte meist nur der Hoster. Schneller wird die Seite dadurch nicht, sie scheitert nur später.
Ist 504 dasselbe wie der Fehler 524 bei Cloudflare?
Fast. Beides ist eine Zeitüberschreitung. Der 504 kommt meist vom Webserver oder Proxy vor WordPress, der 524 von Cloudflare selbst, wenn Dein Server innerhalb der Wartezeit keine Antwort schickt.

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