Plesk und Nginx in 2021

In diesem Beitrag gehe ich auf die Verbesserungen ein, die Plesk bei der Konfiguration von Nginx in den letzten Jahren nach und nach eingebracht hat, insbesondere die im Januar 2021 bereitgestellte Brotli-Komprimierung – die standardmäßig eingeschaltet ist. Zudem werden Custom Templates für Nginx erläutert, den Stand bei Plesk von ModSecurity für Nginx untersucht, Nginx Caching erklärt und WordPress-Plugins empfohlen, die Nginx berücksichtigen.

Plesk bietet den Webserver Nginx seit über 6 Jahren als schnellere und resourcenschonende Alternative zu Apache an. Nach standardmäßiger Plesk-Konfiguration (soweit das Nginx-Modul installiert ist) liefert Nginx alle Dateien der Webseite selbst aus, verwendet aber Apache im Hintergrund um z.B. PHP-Dateien auszuführen oder endgültige Dateinamen- und Pfade zu ermitteln. In dieser Konfiguration funktioniert Nginx als ein Reverse-Proxy Server. Der Hauptvorteil des Doppelpacks ist die Geschwindigkeit von Nginx aber ohne Probleme, weil die herkömmlichen .htaccess Dateien, die das Verhalten von Apache modifizieren, weiterhin greifen.

Je mehr man jedoch auf Apache verzichtet, umso mehr muss man das Wirken der .htaccess Dateien in der (statischen) Konfiguration von Nginx berücksichtigen. Das ist bei jeder Web-Software eine neue Herausforderung – WordPress, Drupal, Nextcloud, bbPress, Zabbix, WHMCS… alle brauchen eigene Konfigurationen für Nginx. Der Lohn dafür ist die Geschwindigkeit und Resourcenschonung, gerade wenn eine Website stark besucht ist zahlt sich das aus. Das liegt zum einen an der Konzeption von Nginx, aber auch daran dass er, im Gegensatz zu Apache, nicht bei jedem Zugriff in jedem Verzeichnis im Pfad schauen muss, ob eine (geänderte) .htaccess Datei nun vorliegt.

Lohnt es sich auf eine reine Nginx-Lösung umzusteigen? Ich meine in vielen Fällen ja – und die WordPress-Macher stimmen mir indirekt zu, siehe diesen Nginx-Artikel bei wordpress.org. Wenn mindestens eine Website an einem Server gut besucht ist, dann soll man den Nginx-Weg für diese Website gehen – und dann kann man ihn auch für etwaige andere Websites auf dem Server einrichten, damit alle konform gehen.

Ich habe bereits mitte 2014 einen Artikel über Nginx und PHP-FPM bzw. einen 33-seitigen PDF geschrieben, der in seinen Grundsätzen noch erstaunlich aktuell ist. Zumal einige Schwächen in der Art wie Plesk Nginx PHP-FPM konfiguriert immer noch vorhanden sind, und von mir kürzlich als Bug-Report wieder angesprochen wurden – möge es bald Abhilfe geben.

Andererseits hat sich in den vergangen Jahren, und auch erst wieder kürzlich, einiges an Fortschritte gegeben wie Plesk Nginx konfiguriert und neue Features in Nginx anbietet. Grund genug, sie zu prüfen und die eigenen Gewohnheiten, Plesk – Nginx zu konfigurieren, zu überprüfen:

  1. Kann man inzwischen auf das eigene „Custom Template“ nginxDomainVirtualHost.php verzichten?
  2. Plesk bietet nun „ModSecurity“ für Nginx an – was ist das und soll man es einschalten?
  3. Welche WordPress-Plugins bieten Nginx-Konfigurationsergänzungen direkt an?
  4. Soll ich Nginx caching in Plesk einschalten (Antwort: eher Nein)
  5. Seit Version 18.0.33 (Anfang Februar 2021) schaltet Plesk das Brotli-Komprimierungsverfahren in Nginx standardmäßig ein – was ist das, was soll man tun?

Braucht man noch Custom Templates für Nginx?

Im oben verlinkten PDF steht auf Seite 13 eine veraltete Beschreibung „Alternative: Die Kontrolle an sich reißen“. Veraltet weil man mit Plesk heutzutage PHP-FPM per Nginx direkt in der Plesk-GUI einstellen kann. Dafür ist der Abschnitt „Die letzte Rettung: Custom Configuration Template“ auf Seite 15 noch voll aktuell; hier die aktuelle Beschreibung bei Plesk. Es ist und bleibt aber unschmackhaft, eigene Custom Templates zu benutzen – denn bei jedem Plesk-Update muss man sie kontrollieren und ggf. ergänzen.

Im oben erwähnten Bug-Report habe ich die immer noch vorhandenen Schwächen in den von Plesk erzeugten Nginx-Config für PHP-FPM detailliert dargestellt und um Behebung gebeten. Zum Zeitpunkt des Schreibens steht der Report auf dem Zustand „Forwarded to devs“ – somit wissen wir nicht, ob sie (bald) darauf eingehen werden. Wenn sie es tun, so weit dass ich damit zufrieden sein kann, dann werde ich künftig definitiv auf ein eigenes Nginx-Template verzichten.Wenn nicht, bin ich unentschieden – es gibt (dort notiert) ein „workaround“ für das Problem dass WordPress Blogartikel nicht gefunden werden (per nginx rewrite). Aber dann ist die eigene, reguläre Zusatzconfig für Nginx mehr „verkünstelt“ und mögliche Auswirkungen davon schwer einzuschätzen.

Doch es gibt weitere Faktoren für eine Entscheidung, was man nun insgesamt bzgl. Nginx-Config machen soll…

Plesk’s Angebot: ModSecurity für Nginx

Zunächst der Wikipedia-Eintrag zu ModSecurity. Leider nur auf Englisch verfügbar, daher der erste Absatz davon per DeepL übersetzt:

ModSecurity, manchmal auch Modsec genannt, ist eine Open-Source-Web Application Firewall (WAF). Ursprünglich als Modul für den Apache HTTP Server entwickelt, hat es sich weiterentwickelt, um eine Reihe von Hypertext-Transfer-Protokoll-Anfrage- und Antwort-Filter-Funktionen zusammen mit anderen Sicherheitsfunktionen über eine Reihe von verschiedenen Plattformen einschließlich Apache HTTP Server, Microsoft IIS und Nginx zu bieten. Es ist eine freie Software, die unter der Apache-Lizenz 2.0 veröffentlicht wird.

Es gibt eine Implementierung von ModSecurity für Nginx seit 2017, so dass es inzwischen ausgereift für den produktiven Einsatz sein dürfte. Erst in der zweiten Hälfte von 2020 kam dann das Angebot von Plesk – zunächst von Plesk selbst als „mit Vorsicht zu genießen“ ausgezeichnet, inzwischen nicht mehr.

Achtung: Am Ende der (recht brauchbaren) Plesk-Beschreibung zu ModSecurity steht (zum Zeitpunkt des Schreibens), dass es ModSecurity nur für Apache gibt. Das ist aber veraltet, im Changelog zu Plesk Obsidian 18.0.32 (freigegeben am 8.12.2020) steht dass ModSecurity für Nginx hinzugefügt wurde.

Achtung: Die o.g. Plesk-Beschreibung weist darauf hin, dass am eigenen Server ein lokaler DNS-Server eingerichtet sein soll, um aus ModSecurity stammenden DNS-Anfragen lokal zu cachen. Sonst könnte die Abarbeitung von HTTP-Anfragen spürbar verlangsamt werden. Wer ausschließlich seine Domains bei externen Providern verwaltet, hat womöglich aber das Bind-Modul im Plesk-Installer längst abgewählt (wie ich). Dann muss sie eben wieder installiert werden. Test ob Bind funktioniert (auf Shell-Ebene):
dig yourdomain.tld @127.0.0.1

Zunächst muss man per Plesk Installer „Web hosting | ModSecurity“ installieren. Und dann im Plesk GUI unter „Tools & Einstellungen | Sicherheit | Web Application Firewall“ aktivieren. Hierbei gibt es die Wahl zwischen „Nur Erkennung“ und „Ein“; die theoretischen Unterschiede sind im oben verlinkten Plesk-Artikel gut beschrieben. Wer vorsichtig vorgeht – zu empfehlen – kann erst „Nur Erkennung“ wählen, und im Laufe der nächsten Tage die ModSecurity Protokolle prüfen (bequem in der Plesk-GUI), was es alles blockiert hätte.

Sobald man ein Radio-Button „Nur Erkennung“ oder „Ein“ auswählt, erscheint im gleichen Plesk-Dialog darunter ein weiterer Bereich, wo man einen „Regelsatz“ auswählen muss. Das sind die Regeln, die steuern, wie die HTTP-Anfragen untersucht werden sollen – denn ModSecurity selbst ist nur ein Framework, leben tut es erst mit einem Regelsatz. Dabei bietet Plesk die gängigsten Regelsätze direkt zur Auswahl an – mit den Haken dass (a) manche davon kostenpflichtig sind und eine davon (Comodo) gratis aber registrierungspflichtig, und (b) man sowieso vor der Qual der Wahl steht. Ich habe mich im Internet informiert und lese, dass i.A. der Comodo-Regelsatz „benutzerfreundlich“ sei und nach Konsensmeinung die wenigsten „false positives“ erzeugt.

Zunächst aber muss man in der Dropdown „Regeln ausführen auf“ eben „Nginx (ModSecurity 3.0)“ wählen. Danach will man unter 5 angebotenen Regelsätzen seine Wahl treffen – aber jetzt, für Nginx, sind nur OWASP (zu streng) und Benutzerdefinierter Regelsatz auswählbar – Upps. Beide indiskutabel, hier müsste man Comodo wählen und seine gratis-erworbene Comodo-Kennung angeben können.

Im Changelog für Plesk 18.0.32 steht: At the moment you can only choose the OWASP ruleset in the Plesk UI for ModSecurity 3. You can download the Comodo ruleset and upload it to Plesk as a custom ruleset. We plan to make it possible to enable the Comodo ruleset for ModSecurity 3 directly from the Plesk UI in Plesk Obsidian 18.0.33.

Das ist aber in 18.0.33 leider noch nicht passiert. Fazit:
Wir sind zu früh daran – abwarten.

WordPress-Plugins die Nginx-Konfigurationsergänzungen direkt anbieten

Das soll hier keine ausführliche Liste sein. Ich erwähne nur die Plugins, die mir für Nginx-Unterstützung bekannt und im Einsatz sind. Von den Anforderungen her sind es am ehesten Sicherheits- und Cache-Plugins, die Veränderungen an der Webserver-Konfiguration vornehmen müssen.

  1. iThemes Security unterstützt bereits seit Jahren Nginx: Es schreibt einen Abschnitt mit Nginx-Regeln in eine Datei {docroot}/nginx.conf. Diese Datei wird nicht automatisch von Nginx gefunden, vielmehr muss man es in der eigenen Nginx-Config includieren. Die Regeln schützen z.B. Dateien und Verzeichnisse vor direkten Zugriffen, oder sperren bekannte Spambots aus.
  2. W3 Total Cache („W3TC“) benutzt ebenfalls diese Konvention und screibt seine Regeln zur Steuerung von Server- und Browser-Cachingverhalten in einen Abschnitt in dieselbe Datei. Die beiden vertragen sich also bestens und man selbst muss nur die eine Datei includieren.
  3. In letzter Zeit habe ich WP Cerber ausgewählt als Plugin das sowohl Hacking- und Malware als auch Spam-Angriffe entgegenwirkt. Noch berücksichtigt es Nginx nicht – aber ich konnte dem Autor per Support-Anfrage dazu bewegen, dass er versprochen hat, sich das Thema in Bälde anzunehmen.
  4. SEOPress

Soll ich Nginx caching in Plesk einschalten?

Schon länger bietet Plesk die Möglichkeit an, Caching in Nginx einzuschalten – {Website} | Einstellungen für Apache & nginx | nginx-Einstellungen | nginx-Caching aktivieren. Aber was bewirkt das, und ist es zu riskant? Zumal Plesk selbst dort schreibt: Caching kann die Reaktionszeit Ihrer Website, sowie die Serverauslastung verringern, sollte jedoch mit Vorsicht ausgeführt werden.

Ein kurzes Studium der Nginx-Literatur dazu – hier und hier – reicht um festzustellen, dass Nginx dann Kopien der auszuliefernden Dateien in einem eigenen Disk-Cache bereithält. Das mag einiges bringen, wenn Nginx als „Reverse Proxy“, also im Doppelpack mit Apache, benutzt wird, denn dann kann auf die Anfragen an Apache i.W. verzichtet werden und die Ergebnisdateien, die Apache einmal bereitstellt, immer wieder ausgeliefert werden. Damit handelt man sich allerdings ein großes Problem ein – wie soll Nginx feststellen ob die Ergebnisdateien noch aktuell sind, bzw. wovon ihre Aktualität abhängt? Unabhängig davon könnte ein Vorteil sein, dass Nginx dann fertig komprimierte Dateien (gzip oder brotli) vorhält, und sie nicht jedes Mal aufs Neue komprimieren muss.

Auch in der reinen Nginx-Lösung gibt es (abgesehen von vorkomprimierten Dateien) ein Szenario wo Nginx-Caching sinnvoll wäre – nämlich dann, wenn z.B. PHP-Dateien (mühsam) ausgeführt werden um den Inhalt einer Webseite zusammenzustellen. Ist das Ergebnis jedesmal gleich (z.B. Website ist „statisch“, d.h. erlaubt kein Login, kein Blogging etc.) dann wäre Nginx-Caching durchaus sinnvoll – wenn keine andere Instanz das nicht schon (besser) macht.

  • WordPress und andere CMSen
    Solche Programme haben alle eigene Caching-Plugins, die viel besser situiert sind zu beurteilen, wann eine Cache-Kopie veraltet ist. So fällt hier die Antwort eindeutig aus: Nein, kein Caching per Nginx.
  • Selbstgeschriebene Websites ohne eigenes Caching
    Ein gutes Beispiel aus meiner eigenen Arbeit ist hier Biblische Reisen. Ich habe die Website in PHP und jQuery Mobile realisiert, und auch den Import der aktuellen Reisedaten aus einem betriebsinternen System. Jeder Seitenabruf läuft momentan den ganzen Weg durch PHP, um die Seite zurückzuliefern. Dank OPCache und einen flotten Server mit großzügigen PHP-FPM Einstellungen, reicht diese Konfiguration für die aufkommenden Besucherzahlen vollkommen. Google PageSpeed Insights vergibt hier für Desktop 92 Punkte, die Auslieferung der PHP-Seite selbst dauert ca. 120 bis 180 Millisekunden. Ein Gewinn wäre mit Caching daher eher gering, und würde den Aufwand, eine Strategie zur Löschung des Cacheinhalts bei neuen Reisedaten zu entwickeln, nicht rechtfertigen.

Fazit: Caching in Nginx könnte (mit viel Vorsicht) sinnvoll sein, wenn Nginx als Reverse Proxy betrieben wird, oder bei extrem hoher Last (vorkomprimierte Dateien). Wird nur Nginx als Webserver benutzt, dürfte es nur wenige Szenarien geben, für die ein Caching so vorteilhaft wäre dass es den vermutlich bedeutenden Zusatzaufwand rechtfertigt.

Plesk und das Brotli-Komprimierungsverfahren in Nginx

Seit Version 18.0.33 (Anfang Februar 2021) schaltet Plesk das Brotli-Komprimierungsverfahren in Nginx standardmäßig ein. Wird Brotli nicht weiter konfiguriert (defacto zunächst der Fall) und es bleibt sonst die bisherige individuelle Konfiguration in Kraft, dann kann es in wenigen Fällen zu widerspruchlichen Antwort-Headers kommen. Plesk Doku beschreibt, wie man pro Domain oder insgesamt Brotli abschalten kann.

Aber erstmal: Brotli ist ein Kompressionsverfahren, das ähnlich wie beim eher bekannten Zip (bzw. gzip) Dateien packt bzw. komprimiert. Der Webserver packt die auszuliefernden Dateien und sendet die kürzeren Fassungen über das Internet zum Webbrowser, wo sie wieder entpackt werden vor ihrer Nutzung. Wenn die Zeit für das (Ent-)packen weniger beträgt als die Zeitdifferenz, die Originalfassungen über das Internet zu schicken, hat man einen Geschwindigkeitsgewinn (und belastet das Internet auch etwas weniger). Leider gibt es auf Deutsch nur wenig Information zu Brotli; hier auf Wikipedia, und hier auf englisch einen Vergleich von Brotli und Gzip. Unter dem Strich macht Brotli Dateien im Schnitt ca. 17% kleiner als Gzip.

Ab Plesk 18.0.33 sieht die Plesk-Config bzgl. komprimierte Auslieferung so aus:

  • Verfügbare Zusatzmodule sind: brotli.load, modsecurity.load, pagespeed.load
  • Ohne unser Dazutun werden per /etc/nginx/modules.conf.d/brotli.conf zwei Brotli-Module geladen (für „on the fly“ und Vorkomprimierung).
  • Und ebenfalls ohne Dazutun steht in /etc/nginx/conf.d/brotli.conf – der in http Kontext geladen wird:
    brotli on;
    brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
  • Hier eine Liste der verfügbaren Brotli-Direktive für Nginx. Dort fällt auf, dass Plesk auf die Direktive „brotli_comp_level“ verzichtet hat – der Default ‚6‘ (von 0 – 11) liegt in der Mitte und ist verm. ein guter Kompromiss zwischen gepackter Größe und die Zeit für das Packen.
  • In der Annahme, der Browser sagt im Request-Headers „accept-encoding: gzip, deflate, br“, und man hat in der eigenen Nginx-Config „gzip on“ (usw.) – was in Nginx’s server Kontext inkludiert wird: Dann anscheinend „trümpft“ die Brotli-Anweisung im http Kontext die Gzip-Anweisung im server Kontext, es wird tatsächlich ein Antwort-Header „content-encoding: br“ erzeugt und die Komprimierung dürfte dann wohl Brotli sein.
  • Das kann man sogar als elegant ansehen: Akzeptiert der Browser Brotli, dann wird Brotli benutzt, ansonsten die Gzip-Encoding wie bisher. Also, hier besteht kein Grund die eigenen Gzip-Anweisungen zu entfernen.
  • Handlungsbedarf gibt es jedoch bei WordPress mit W3 Total Cache: Das Plugin ist echt super – es macht sich die Mühe (wenn so konfiguriert) minimierte Dateien schon vorab per Gzip zu encodieren, und damit die Last der wiederholten Komprimierung durch den Webserver zu vermeiden. Dafür muss es selbst die Antwort-Header „content-encoding: gzip“ hinzufügen. Endergebnis: In der Antwort stehen beide Headers )-: So muss man entweder in W3TC die Vorkomprimierung per Gzip ausschalten, oder Brotli in der eigenen Domain-Config ausschalten („brotli off;“). Allerdings: W3TC bietet auch Brotli-Vorkomprimierung – wenn das entsprechende Zusatzmodul in PHP geladen ist (mehr hier) – was eher unwahrscheinlich ist, weil man (noch) das Modul hier abholen und selber kompilieren muss. Womöglich lohnt sich die Mühe: Die Direktive „brotli_comp_level“ gilt nur für „on the fly“ Komprimierung – was ahnen lässt, dass wenn Dateien vorkomprimiert vorgehalten werden, die maximale Komprimierung genutzt wird – ein gutes Argument, das Brotli-Modul in PHP zu integrieren so dass W3TC es nutzen kann.

Fazit mitte Februar 2021: Noch nicht handeln

abgesehen von der oben erwähnten Problematik mit W3 Total Cache. Sonst:

  1. Auf ein „Custom Template“ nginxDomainVirtualHost.php zu verzichten soll erst entschieden werden, wenn wir von den Plesk-Entwicklern hören zu meinen Verbesserungsvorschlägen.
  2. Bei ModSecurity warten wir auf eine Plesk-Version, die den Comodo-Regelsatz unterstützt.
  3. Derweil hoffe ich persönlich auf baldige Nginx-Unterstützung in WP Cerber.
  4. Nginx-Caching soll nur in besonderen Fällen verwendet werden.
  5. Die Brotli-Komprimierung läuft „out of the box“, und verträgt sich mit eigenen Gzip-Anweisungen.

Über das Eintreten erhoffter Änderungen werde ich hier berichten.

Noch keine Kommentare

zu Plesk und Nginx in 2021

Schreibe einen Kommentar

Bitte alle Felder ausfüllen

Untenstehende Gleichung bitte lösen * Zeit abgelaufen. Bitte das CAPTCHA nochmal laden.