Funktion des NGINX-Reverse-Proxys

Wie funktioniert der vorgeschaltete NGINX als Reverse-Proxy?

Der schlanke NGINX

Der NGINX-Webserver wurde im Jahr 2004 von Igor Sysoev entwickelt und unter der BSD-Lizenz veröffentlicht. Der Webserver wurde speziell, auf die Bedürfnisse von Internetseiten mit sehr hohem Traffic entworfen und entwickelt.

Aufgrund der Vielfältigkeit seines modularen Aufbaus, der guten Konfiguration und der hohen Leistung durch den schlanken Aufbau, wird er bei vielen großen Anbietern gerne eingesetzt.

Nginx unterstützt über verschiedene Zusatzmodule Lastverteilung, Namens- und IP-basierte VHosts, FCGI, SSL oder auch Reverse Proxying.

Der altbekannte Apache

Fast 10 Jahre vor NGINX entstand Apache aus dem Webserver NCSA HTTPd welcher bei der Entwicklung des WorldWideWebs eine tragende Schlüsselrolle spielte. Der quelloffene Apache-Webserver wird bislang von der Apache Software Foundation ständig weiterentwickelt und gepflegt.

Apache ist nach Schätzungen auf gut 65 Prozent aller Webserver weltweit im Einsatz und wegen seiner Skalierbarkeit und seines Modulumfangs sehr geschätzt.

HostPress nutzt beide Webserver gleichzeitig

Wir nutzen in unserer Serverkonfiguration beide Webserver gleichzeitig.
Bei uns ist NGINX als Reverse-Proxy vor Apache geschaltet und kümmert sich um alle statischen Inhalte. Anfragen nach dynamischen Inhalten werden alle an Apache weitergegeben, welche dieser behandelt und verarbeitet.

Der NGINX-Cache

Das Caching kann die Reaktionszeit deiner Website, sowie die Serverauslastung verringern. Hier werden dynamische Anfragen an Apache für wenige Sekunden zwischengespeichert. Der NGINX-Zwischenpeicher ist standardmäßig deaktiviert!

Der NGINX-Cache macht aber nur Sinn, wenn du enorm viele gleiche dynamische Anfragen im Sekundentakt nicht erneut wieder bearbeiten lassen möchtest.

Durch dir Nutzung von WP-Rocket als Cachingplugin wird die gesamte WordPress-Seite zwischengespeichert und die Nutzung des NGINX-Caches überflüssig und per default deaktiviert. Bis auf den Basic-Tarif erhält jeder Neukunden eine kostenlose Lizenz dieses Plugins.

Diese Option hat aber nichts damit zu tun, ob der Reverse-Proxy arbeitet und sollte mit Vorsicht ausgeführt werden, da es zu Fehlfunktionen auf deiner Webseite kommen kann.

Nginx-Cache und WP Rocket: Was du wissen solltest

Viele Kunden mit WP Rocket fragen sich, ob sie zusätzlich das Nginx-Caching auf dem Server einschalten sollten und wo sie die Einstellung finden. Hier die wichtigsten Antworten.

Brauche ich das Nginx-Caching, wenn ich WP Rocket nutze?

Nein. WP Rocket legt fertige HTML-Seiten deiner WordPress-Website als Cache-Dateien ab. Der vorgeschaltete NGINX liefert diese Dateien zusammen mit den übrigen statischen Inhalten direkt aus. Ein zusätzlicher Nginx-Seiten-Cache bringt in diesem Setup keinen spürbaren Vorteil, deshalb ist er bei HostPress standardmäßig deaktiviert.

• WP Rocket ist bei uns der zentrale Seiten-Cache für deine WordPress-Website.
• Nginx-Caching bleibt deaktiviert, solange du keinen besonderen Grund für die Aktivierung hast.
• Sind beide Caches gleichzeitig aktiv, gibt es zwei Cache-Ebenen. Leerst du nur den WP-Rocket-Cache, kann der Nginx-Cache noch veraltete Inhalte ausliefern.

Ich finde die Einstellung „Apache- & nginx-Einstellungen“ in Plesk nicht

Je nach Abonnement wird dir diese Kachel in Plesk nicht angezeigt. Das ist kein Fehler. Für den normalen Betrieb mit WP Rocket brauchst du die Einstellung nicht, weil das Nginx-Caching ohnehin deaktiviert bleiben soll. Wenn du das Nginx-Caching aus einem bestimmten Grund prüfen oder ändern möchtest, wende dich an unseren Support.

Hast du das Nginx-Caching selbst aktiviert? So leerst du beide Caches

1. Leere zuerst den WP-Rocket-Cache im WordPress-Backend über WP Rocket > Cache leeren.
2. Leere danach den Nginx-Cache in Plesk an der Stelle, an der du das Nginx-Caching aktiviert hast.
3. Prüfe die Seite in einem Inkognito-Fenster (siehe Wie leere ich meinen Cache?).
4. Wenn du keinen konkreten Grund für das Nginx-Caching hast, deaktiviere es wieder. So vermeidest du Darstellungsfehler durch doppeltes Caching.

Wie wärme ich den Cache nach dem Leeren automatisch wieder auf?

Den Cache wärmst du über WP Rocket auf, nicht über den Server. Mit der Vorlade-Funktion erstellt WP Rocket die Cache-Dateien nach dem Leeren automatisch neu. So bekommt auch der erste Besucher eine schnelle, bereits gecachte Seite.

1. Öffne im WordPress-Backend Einstellungen > WP Rocket.
2. Wechsle in den Reiter Vorladen (Preload).
3. Aktiviere die Option zum Vorladen des Caches und klicke auf Änderungen speichern.
4. Ab jetzt baut WP Rocket den Cache nach jedem Leeren im Hintergrund wieder auf. Grundlage sind deine Sitemap und die internen Links.

Gut zu wissen: Das Vorladen läuft über die geplanten Aufgaben von WordPress. Hast du WP-Cron deaktiviert, muss ein Server-Cronjob eingerichtet sein, damit das Vorladen zuverlässig arbeitet (siehe Cronjobs bei HostPress).

Weiterleitungen: .htaccess oder nginx?

Weiterleitungen (z. B. eine Domain oder eine einzelne Datei auf eine andere Adresse) kannst du in der Regel über die .htaccess im Ordner httpdocs einrichten. Die Datei wird vom Apache-Webserver ausgewertet, der hinter dem nginx-Reverse-Proxy läuft.

• Prüfe in Plesk unter dem Hosting-Typ, ob die Einstellung auf Weiterleitung statt auf Webseite steht. Bei Letzterem überschreibt Plesk deine .htaccess-Regel.
• Verwende für dauerhafte Weiterleitungen den Statuscode 301, z. B. Redirect 301 / https://deine-ziel-domain.de/.
• Header-Regeln aus der .htaccess wirken nicht auf dem nginx-Layer. Solche Regeln müssen auf Serverebene hinterlegt werden.

Weiterleitungen für PDF-, ZIP- und andere statische Dateien greifen nicht

Statische Dateien wie PDFs oder ZIP-Archive liefert der vorgeschaltete nginx direkt aus. Diese Anfragen erreichen den Apache-Webserver nicht, deshalb wertet er die .htaccess für sie nicht aus. Eine Regel wie Redirect 301 /alt/dokument.pdf https://deine-domain.de/neu/dokument.pdf hat dann keine Wirkung, auch wenn sie bei deinem bisherigen Anbieter funktioniert hat. Das fällt oft erst nach einem Umzug zu HostPress auf.

Woran du das erkennst

• Weiterleitungen für normale Seiten funktionieren, Weiterleitungen für Dateien mit Endungen wie .pdf oder .zip dagegen nicht.
• Die alte Datei-URL liefert einen Fehler 404 oder landet auf der Startseite, statt auf die neue Adresse weiterzuleiten.

Was du tun kannst

1. Prüfe, ob die betroffenen URLs auf eine Dateiendung wie .pdf oder .zip enden.
2. Schreibe dem Support die betroffene Domain, die Dateiendungen und je ein Beispiel mit alter und neuer URL.
3. Der Support prüft, ob für diese Dateiendungen eine Ausnahme eingerichtet werden kann. Dann gehen die Anfragen an Apache und deine .htaccess-Regeln greifen wieder. Andere statische Inhalte wie CSS, JavaScript und Bilder liefert nginx weiterhin direkt aus.
4. Teste die Weiterleitungen danach in einem Inkognito-Fenster.

WooCommerce: Download-Produkte sind ohne Kauf abrufbar

WooCommerce legt verkaufte Dateien im Ordner wp-content/uploads/woocommerce_uploads/ ab und schützt diesen Ordner mit einer .htaccess-Datei. Weil nginx statische Dateien wie PDFs direkt ausliefert, wird diese .htaccess für solche Dateien nicht ausgewertet. Wer den direkten Link kennt, kann die Datei dann ohne Kauf herunterladen.

So prüfst du das

1. Kopiere aus einer Testbestellung den direkten Pfad einer Download-Datei, zum Beispiel https://deine-domain.de/wp-content/uploads/woocommerce_uploads/beispiel.pdf.
2. Öffne die URL in einem Inkognito-Fenster, ohne eingeloggt zu sein.
3. Wird die Datei angezeigt oder heruntergeladen, ist der Ordner nicht geschützt.

Was du tun kannst

1. Stelle in WooCommerce unter Einstellungen → Produkte → Downloadbare Produkte die Download-Methode auf Erzwungene Downloads. Dann liefert WooCommerce die Dateien über PHP aus und prüft den Kauf.
2. Bitte den Support, für den Ordner woocommerce_uploads den direkten Zugriff auf nginx-Ebene zu sperren. Nenne dabei die Domain und die betroffenen Dateiendungen.
3. Teste danach erneut im Inkognito-Fenster. Der direkte Aufruf muss jetzt mit „403 Forbidden“ abgewiesen werden, der Download über „Mein Konto“ muss weiter funktionieren.

Individuelle nginx-Regeln

Regeln, die direkt auf der nginx-Ebene greifen müssen (z. B. eine gezielte Weiterleitung einer Datei wie /ads.txt auf eine externe Adresse), kannst du in Plesk nicht selbst anlegen. Schreibe dazu den Support mit der genauen Quelle und dem gewünschten Ziel. Der Support prüft, ob die Regel umgesetzt werden kann.