Warum funktioniert FastCGI-Cache in nginx mit WordPress bei mir nicht?
Hallo zusammen,
ich versuche seit mehreren Tagen, bei einer WordPress-Seite FastCGI-Caching über nginx einzurichten – ohne Erfolg.
Ich habe einen eigenen VPS (Ubuntu 22.04, Plesk, nginx als Webserver), die Seite läuft auf PHP 8.3 + WordPress (Hello Elementor Theme).
Ich habe wirklich alles ausprobiert – kurz zusammengefasst:
Was funktioniert:
Eine test.php-Datei wird korrekt gecached (zeigt X-Cache-Status: HIT)
nginx-Konfiguration ist syntaktisch korrekt (nginx -t = ok)
Cache-Ordner ist vorhanden (/var/cache/nginx/wordpress) und www-data bzw. nginx gehört der Ordner
fastcgi_cache_key, fastcgi_cache_path etc. alles sauber gesetzt
Testweise WP_CACHE aktiviert und Redis komplett deaktiviert
Alle JetEngine- und Crocoblock-Plugins deaktiviert
Auch andere Caching-Plugins wie WP Super Cache, FlyingPress etc. getestet → kein HIT, nur MISS
functions.php auf Sessions geprüft – kein session_start() vorhanden
Was NICHT funktioniert:
Normale WordPress-Seiten (auch eigens angelegte Cache-Testseite /cachetest/) werden niemals gecached (immer X-Cache-Status: MISS)
Auch wenn ALLE Plugins deaktiviert sind → weiterhin MISS
Auch mit angepasstem headers_list() sehe ich, dass WordPress immer Set-Cookie + PHPSESSID setzt
Ich wäre so dankbar über Hilfe.
Weiß langsam echt nicht mehr weiter - danke!
Beste Grüße,
Stefan
1 Antwort
Der Kern der Sache liegt darin, dass Nginx standardmäßig keine Seiten zwischenspeichert, die einen "Set-Cookie"-Header enthalten. WordPress, selbst ohne zusätzliche Caching-Plugins und sogar für nicht angemeldete Benutzer, setzt oft solche Cookies (wie PHPSESSID oder andere). Das führt dazu, dass Nginx diese Seiten als dynamisch ansieht und sie nicht cached, was den "X-Cache-Status: MISS" erklärt, während eine einfache test.php-Datei ohne solche Cookies korrekt gecached wird.
Um das zu beheben, musst du deine Nginx-Konfiguration (i.d.R. nginx.conf) anpassen. Du musst Nginx anweisen, den "Set-Cookie"-Header für die Cache-Entscheidung zu ignorieren, aber gleichzeitig Ausnahmen definieren. Das erreichst du durch die Direktive:
fastcgi_ignore_headers Set-Cookie;
Gleichzeitig ist es entscheidend, über
fastcgi_cache_bypass
und
fastcgi_no_cache
sicherzustellen, dass bestimmte Cookies, die auf einen angemeldeten Benutzer (z.B. wordpress_logged_in_), den Admin-Bereich oder andere dynamische Inhalte hinweisen, weiterhin ein Caching verhindern. So stellst du sicher, dass nur die anonymen, öffentlichen Seiten aus dem Cache ausgeliefert werden, während der Admin-Bereich und eingeloggte Benutzer immer die aktuelle, dynamische Version der Seite sehen. Achte darauf, deine Tests immer als abgemeldeter Benutzer, idealerweise im Inkognito-Modus des Browsers oder mit
curl
durchzuführen, um korrekte Cache-Status zu erhalten. Passe die Nginx-Konfiguration, insbesondere die Pfade zu PHP-FPM, entsprechend deiner Plesk-Umgebung an, oft in den zusätzlichen Nginx-Anweisungen deiner Domain.
Danke dir nochmal für deine Hilfe – ich wollte kurz ein Update geben, woran es letztlich lag:
Ich hatte alles korrekt nach einem FastCGI-Caching-Tutorial für nginx umgesetzt (inkl.
fastcgi_cache_path
,
fastcgi_cache
,
fastcgi_no_cache
,
Set-Cookie
ignorieren etc.). Der Cache funktionierte auch – aber nur so lange, bis ich das WordPress-Plugin „Personio Integration“ aktiviert habe.
Das Problem:
Das Plugin setzt intern immer eine PHP-Session mit
session_start()
, selbst auf Seiten, wo es eigentlich gar nicht gebraucht wird (also z. B. die Startseite, Impressum etc.). Dadurch wird für alle Seiten ein
Set-Cookie: PHPSESSID
-Header generiert – was Caching effektiv blockiert. Trotz
fastcgi_ignore_headers Set-Cookie;
wurde weiterhin
X-Cache-Status: MISS
angezeigt.
Ich habe dann nach und nach Plugins deaktiviert und gemerkt: Nur wenn Personio aus ist, kommt ein
X-Cache-Status: HIT
. Damit war klar, dass genau dieses Plugin die Ursache war.
Ich bin nun mit dem Plugin-Team in Kontakt.
Beste Grüße & hab einen schönen Tag,
Stefan