Was ist NGINX?
NGINX ist ein quelloffener Webserver, geschrieben von Igor Sysoev und heute von F5 gepflegt. Ihn einen Webserver zu nennen greift zu kurz: in den meisten Installationen erledigt er drei oder vier Aufgaben gleichzeitig, und zu wissen, welche davon du brauchst, ist die ganze Entscheidung.
Die vier Aufgaben
Statische Dateien ausliefern. HTML, Bilder, Stylesheets, JavaScript, direkt von der Platte. Das kann er sehr gut, und er braucht dafür sehr wenig Arbeitsspeicher.
Reverse Proxy. Anfragen kommen bei NGINX an und werden an eine Anwendung dahinter weitergereicht. Die Anwendung steht nicht im Internet, muss kein TLS beherrschen und lässt sich neu starten, ohne dass am Rand Verbindungen abreissen.
Load Balancer. Dasselbe, verteilt über mehrere Instanzen, mit Health Checks, damit eine ausgefallene keinen Verkehr mehr bekommt.
HTTP-Cache. Antworten aufbewahren, damit die Anwendung sie nicht neu erzeugen muss. Weniger fein einstellbar als ein eigener Cache, und oft ausreichend.
Die meisten echten Installationen nutzen alle vier, weshalb die Frage "was ist NGINX" verwirrende Antworten bekommt. Es ist ein Prozess, der genau das tut, was du konfiguriert hast.
Warum es das Frühere verdrängt hat
Der Unterschied in der Architektur ist einen Absatz wert, denn er erklärt den Ruf. Ältere Server behandelten jede Verbindung mit einem Prozess oder Thread, tausend gleichzeitige Verbindungen hiessen also tausend davon, die meisten untätig und alle mit Arbeitsspeicher belegt.
NGINX ist ereignisgetrieben: wenige Worker-Prozesse bedienen je viele Verbindungen und arbeiten nur dann, wenn eine Verbindung tatsächlich etwas mitzuteilen hat. Untätige Verbindungen kosten fast nichts. Deshalb hält es viele gleichzeitige Verbindungen mit bescheidenem Arbeitsspeicher, und deshalb wurde es zum Standard vor Anwendungen, die das nicht konnten.
Quelloffen, NGINX Plus und NGINX One
Hier sitzt die meiste Verwirrung, und es ist eine Beschaffungsfrage und keine technische.
Das quelloffene NGINX ist die Software von oben: kostenlos, von fast allen betrieben, und für die grosse Mehrheit der Installationen vollständig ausreichend.
NGINX Plus ist die kommerzielle Ausgabe von F5 und ergänzt unter anderem weitergehendes Verhalten bei der Lastverteilung, Session Persistence, reichhaltigeres Monitoring und eine API zum Umkonfigurieren ohne Reload, dazu Herstellersupport.
NGINX One ist die neuere Verpackung von F5 rund um das kommerzielle Angebot.
Was Plus hinzufügt, in den Worten von F5: weitergehende Verkehrssteuerung, Sicherheit und Observability über dem quelloffenen NGINX. Zwei Fähigkeiten erklären die meisten Käufe.
Authentifizierung am Rand, über die Prüfung von JWT. NGINX Plus kann ein JSON Web Token prüfen, bevor die Anfrage deine Anwendung erreicht: es prüft Signatur, Ablauf und die Claims, die du verlangst, und weist ab oder leitet um, was durchfällt. Signierte, verschlüsselte und verschachtelte Tokens werden alle unterstützt.
Die praktische Form ist die, die Leute wollen: eine Anfrage ohne gültiges Token oder mit einem abgelaufenen wird vom Proxy auf die Anmeldeseite geschickt und nicht von jeder Anwendung dahinter. Damit wandert die Prüfung der Sitzung aus jeder einzelnen Anwendung an eine Stelle, was dasselbe Argument ist, das ein Identitätsanbieter eine Ebene höher macht. Genau deshalb kommt das so oft bei Teams auf, die mehrere Anwendungen und eine Anmeldung haben.
Eine Web Application Firewall, als eigenes Zusatzprodukt. F5 WAF for NGINX, früher NGINX App Protect, ist ein eigenes Produkt und nicht Teil des Plus-Abonnements. Es filtert bösartigen Verkehr, bevor er die Anwendung erreicht, und der Teil, der den Kauf meist auslöst, ist die Abwehr von Bots: umfassender Schutz gegen automatisierte Angriffe und Bots, also gegen das meiste, was eine im Internet erreichbare Anwendung überhaupt erreicht.
Wichtig festzuhalten: das ist eine zweite Position auf der Rechnung. "Wir brauchen die WAF" und "wir brauchen Plus" sind zwei Käufe, und Offerten, die etwas anderes annehmen, sind eine verbreitete Überraschung.
Der übrige Funktionsumfang von Plus ist real und selten der Kaufgrund:
- Aktive Health Checks. Das quelloffene NGINX merkt erst dann, dass ein Backend tot ist, wenn eine Anfrage dort scheitert. Plus prüft Backends eigenständig und nimmt sie heraus, bevor jemand darauf stösst.
- Konfigurationsänderungen ohne Reload. Eine über die API gesteuerte Konfiguration, die Änderungen am Verkehr ohne Reload übernimmt. Das zählt, wenn sich die Upstream-Liste ständig ändert, wie überall dort, wo automatisch skaliert wird.
- Session Persistence über das hinaus, was Hashing liefert, für Anwendungen mit Zustand pro Person.
- Zustandsabgleich und Failover über Instanzen hinweg, damit ein Paar oder Cluster sich wie eines verhält.
- Observability in Echtzeit, also Kennzahlen pro Upstream statt Rückschlüsse aus den Zugriffsprotokollen.
NGINX One ist die 2024 gestartete Verpackung der ganzen Linie durch F5: NGINX Plus, App Protect WAF, Ingress Controller, Gateway Fabric und Instance Manager in einem Abonnement, mit einer SaaS-Konsole für den Überblick über die ganze Flotte, samt Auffinden der Instanzen, Verfolgen von CVE nach Schweregrad und Zertifikatsstatus. Das Argument dafür ist die Flottenverwaltung und nicht eine einzelne Fähigkeit, es greift also, wenn du viele Instanzen hast und die Frage "welche davon ist ungepatcht" nicht beantworten kannst.
Die ehrliche Empfehlung: fang mit dem quelloffenen an. Zur kommerziellen Ausgabe greifst du, wenn du benennen kannst, welche der Fähigkeiten oben du brauchst, und nicht, weil eine Produktseite nahelegt, das Kostenlose sei eine Testversion. In der Praxis entscheidet meist die Frage, ob du Authentifizierung oder Bot-Filterung am Rand haben willst. Wenn keines von beidem, deckt das quelloffene die meisten Installationen mit einer Anwendung dauerhaft ab.
Die Verwirrung um Ingress in Kubernetes, und eine Frist
Wenn du von Kubernetes hierher gekommen bist, ist das, worüber du gelesen hast, vermutlich nicht das schlichte NGINX.
Ein Ingress Controller beobachtet Kubernetes auf Routing-Regeln und erzeugt daraus die Konfiguration für einen Proxy. Mehrere nutzen NGINX als diesen Proxy, und sie sind getrennte Projekte mit anderen Maintainern, anderem Funktionsumfang und Annotationen, die nicht austauschbar sind. "Wir nutzen NGINX" kann innerhalb und ausserhalb eines Gesprächs über Kubernetes also ziemlich Verschiedenes heissen.
Einer davon wird eingestellt, und das ist das Wichtigste auf dieser Seite, wenn du Kubernetes betreibst. Der Controller der Community, Ingress-NGINX, wird zurückgezogen: die Pflege nach Best Effort lief bis März 2026, und das Projekt hält fest, dass es danach keine Releases, keine Fehlerkorrekturen und keine Updates für allfällig entdeckte Sicherheitslücken mehr geben wird. Die eigene Empfehlung lautet, dass ihn niemand neu einsetzen soll, der ihn nicht bereits nutzt.
Das ist keine Deprecation-Meldung zum Ablegen. Eine im Internet erreichbare Komponente, die keine Sicherheitskorrekturen mehr bekommt, ist eine Altlast mit Datum, und Ingress-NGINX gehört zur am weitesten verbreiteten Software im Kubernetes-Ökosystem. Sehr viele Cluster sind also betroffen, und viele ihrer Betreibenden haben es nicht bemerkt.
Wer ihn betreibt, sollte in diesem Quartal zwei Fragen beantworten: wohin es geht, wobei das Projekt auf die Umsetzungen der Gateway API verweist, und wie lange diese Migration dauert, wenn jede Routing-Regel und jede Annotation im Cluster in genau dem Controller ausgedrückt ist, den du verlässt.
Wann du es brauchst
- Ein Anwendungsserver, der nicht direkt im Internet stehen soll. Die meisten Laufzeitumgebungen sind nicht für den Rand gebaut, und das ist die Standardantwort.
- TLS-Terminierung an einer Stelle, damit Zertifikate einmal verwaltet werden und nicht in jeder Anwendung.
- Mehr als eine Instanz von irgendetwas, denn dann muss etwas den Verkehr verteilen.
- Statische Inhalte neben einer dynamischen Anwendung, ausgeliefert, ohne die Anwendung überhaupt zu wecken.
Wann nicht
Eine verwaltete Plattform, die deiner Anwendung bereits vorgelagert ist, hat diese Schicht schon, und eine eigene verdoppelt sie.
Ein CDN allein ist bei einer rein statischen Website ohne dynamischen Ursprung weniger zu betreiben.
Wenn du eigentlich Caching willst, sieh dir einen Cache an, der dafür gebaut ist. NGINX cached, Varnish ist darum herum entworfen, mit einer Konfigurationssprache für Regeln, die NGINX nicht ausdrücken kann.
Was der Betrieb verlangt
- TLS und die Erneuerung der Zertifikate. Automatische Ausstellung ist heute Standard, und diese Automatisierung ist etwas, das still kaputtgehen kann, bis ein Zertifikat abläuft.
- Die Konfiguration lässt sich leicht subtil falsch schreiben. Location Matching, das Weiterreichen von Headern und das Proxy-Buffering verhalten sich korrekt und überraschend. Ein Reload mit einer schlechten Konfiguration ist schlimmer als ein Syntaxfehler, denn ein Syntaxfehler hält wenigstens an.
- Timeouts und Puffergrössen. Die Standardwerte sind vorsichtig und führen bei grossen Uploads und langsamen Backends zu rätselhaften Fehlern.
- Sicherheitspatches. Es ist der Prozess, der im Internet steht.
- Die Protokolle sind das nützliche Signal. In Zugriffs- und Fehlerprotokollen zeigt sich, wo eine Route falsch ist oder ein Backend versagt.
Wo VSHN ins Bild kommt
VSHN rollt NGINX auf Schweizer Infrastruktur aus, überwacht und wartet es, samt der Arbeit an TLS, Konfiguration und Patches von oben, als Teil eines Stacks für Application Delivery und nicht als Komponente für sich.
Wenn du noch entscheidest, was am Rand laufen soll, ist die nützliche erste Frage, welche der vier Aufgaben du tatsächlich hast. Diese Frage verändert die Antwort mehr als die Wahl der Software.