Wir freuen uns, die Verfügbarkeit von NGINX Plus Release 25 (R25) bekannt zu geben. NGINX Plus basiert auf NGINX Open Source und ist der einzige All-in-One- Software-Webserver, Load Balancer, Reverse-Proxy, Inhaltscache und API-Gateway.
Zu den neuen Funktionen in NGINX Plus R25 gehören:
Wie im Abschnitt „Genauere Berichterstattung über HTTP-Antwortcodes“ ausführlich beschrieben, ermöglicht NGINX Plus R25 die Zählung einzelner Statuscodes sowie die Gesamtzählung pro Klasse. Wenn NGINX Plus als Reverse-Proxy oder Load Balancer konfiguriert ist, müssen Sie möglicherweise die Größe der gemeinsam genutzten Speicherzone erhöhen, die zur Überwachung der Upstream-„Peers“ (Backend-Server) verwendet wird, wenn mehr als 20 Peers vorhanden sind.
NGINX Plus R25 startet nicht, wenn gemeinsam genutzte Speicherzonen nicht ausreichend bereitgestellt sind, was zu fehlgeschlagenen Upgrades führt. Vor dem Upgrade ist es wichtig, die Speicherauslastung jeder Upstream-Zone zu überprüfen. Anweisungen zum Überprüfen und Anpassen der Speicherzuweisung finden Sie unter Zuweisen von ausreichend Speicher, um Startfehler zu vermeiden .
Bei der Veröffentlichung von NGINX Plus R24 wurden die Paket-Repositorys für die gesamte NGINX-Software neu organisiert, was zu Änderungen am Installationsverfahren von NGINX Plus führte.
Wenn Sie NGINX Plus installieren oder aktualisieren, wird der Paketmanager des Betriebssystems ( apt
, yum
oder gleichwertig) mit dem Software-Repository für NGINX Plus konfiguriert. Auf vorhandenen Systemen, die für die Verwendung des alten Repo konfiguriert sind (auf denen NGINX Plus R23 oder früher ausgeführt wird), müssen Sie den Paketmanager aktualisieren, um auf das neue Repo zu verweisen. Anweisungen finden Sie in der F5-Wissensdatenbank .
Wenn Sie eine Erstinstallation von NGINX Plus R25 durchführen, finden Sie weitere Informationen unter Installieren von NGINX Plus im NGINX Plus-Administratorhandbuch .
Notiz: Sie müssen das neue Software-Repository verwenden. Das alte Repo wird nicht mehr aktualisiert und kann bei zukünftigen Installationen und Upgrades Fehler verursachen.
Wie bei der Veröffentlichung von NGINX Plus R23 angekündigt, ist das Drittanbietermodul Cookie-Flag veraltet und wird in NGINX Plus R26 aus dem Repository der dynamischen Module entfernt. Die in diesem Modul definierte Direktive set_cookie_flag
wird durch die integrierte Direktive proxy_cookie_flags
ersetzt. Wir empfehlen Ihnen, alle set_cookie_flag
-Direktiven in Ihrer Konfiguration so schnell wie möglich durch proxy_cookie_flags
-Direktiven zu ersetzen.
NGINX Plus R24 führte erstmals Unterstützung für verschlüsselte JSON Web Tokens (JWE) ein und erweiterte damit eine der beliebtesten Methoden der Client-Authentifizierung um Datenvertraulichkeit. NGINX Plus R25 baut auf dieser Fähigkeit auf und führt Unterstützung für zusätzliche und erweiterte Authentifizierungsanwendungsfälle ein, die dazu beitragen, die Sicherheit der JWT-basierten Authentifizierung sowohl für signierte (JWS) als auch für verschlüsselte (JWE) Anwendungsfälle zu verbessern. Die Verbesserungen verringern das Risiko des Verlusts personenbezogener Daten (PII) und bieten mehr Flexibilität. Die neuen JWT-Funktionen und Verbesserungen für NGINX Plus umfassen:
JWTs sind eine weit verbreitete und vertrauenswürdige Methode zur zustandslosen Authentifizierung von HTTP-Anfragen (d. h. tokenbasierte Authentifizierung). Durch die Übertragung von Endbenutzerattributen in der Tokennutzlast tragen JWTs dazu bei, Anforderungen sicherer zu machen. Sicherheitsforscher und DevSecOps-Praktiker sind sich jedoch einig, dass das Risiko, das durch die Speicherung unverschlüsselter PII auf Webclients entsteht, ein dringendes Problem darstellt. Daher wurde der JSON Web Encryption-Standard (RFC 7516) entwickelt, der Richtlinien für die Implementierung verschlüsselter Token bereitstellt.
NGINX Plus R24 führte die Unterstützung für JWE ein und gewährleistet Datenintegrität und Vertraulichkeit für den gesamten Anspruchssatz. Durch die Kodierung von PII im verschlüsselten Token wird das Risiko von Datenlecks bei der Verwendung von JWTs erheblich reduziert.
NGINX Plus R25 baut auf der anfänglichen JWE-Unterstützung mit einer neuen Variable, $jwt_payload
, auf, die es NGINX Plus ermöglicht, JWE und Geheimtext zu entschlüsseln und dann während der Verarbeitung der HTTP-Anfrage auf den Klartext zuzugreifen. Diese neue Funktionalität kann zum Implementieren erweiterter Zugriffskontrollrichtlinien und Anforderungsrouting-Entscheidungen verwendet werden und ermöglicht es Benutzern, NGINX Plus als JWE-Entschlüsselungsschicht für Backend-Anwendungen einzusetzen.
JWE-Token schützen PII wirksam, wobei der Geheimtext dazu dient, die Vertraulichkeit auch über CDNs und andere TLS-terminierende Proxys hinweg zu wahren. Allerdings ist die Verschlüsselung ein zweischneidiges Schwert, da JWEs die Anwendungsumgebung komplexer machen können. Eine Möglichkeit, dieses Problem zu lösen, besteht darin, verschachtelte JWTs zu verwenden.
Verschachtelte JWTs betten JWS als Geheimtext eines JWE ein. NGINX Plus R25 ermöglicht verschachtelte JWTs als Methode zur Authentifizierung von HTTP-Anfragen, indem es sowohl JWS als auch JWE gleichzeitig unterstützt. In einem Vorgang kann NGINX Plus nun den Geheimtext im JWE entschlüsseln, den resultierenden Klartext als JWS validieren und die Angaben „exp“
(Ablaufzeit) und „nbf“
(nicht vorher) im beigefügten Token verwenden, um die Gültigkeit zu überprüfen. Dadurch kann eine vorhandene JWS-Umgebung mit Nutzlastverschlüsselung aktualisiert werden, indem sie in ein JWE eingebettet wird.
Der folgende Konfigurationsausschnitt veranschaulicht den Vorgang. Der neue verschachtelte
Parameter der Direktive auth_jwt_type
weist NGINX Plus an, sowohl die JWE-Entschlüsselung als auch die JWS-Validierung durchzuführen. Es wirkt sich auch darauf aus, wie die Variablen für JWT-Header und JWT-Ansprüche ausgewertet werden:
„auth_jwt_header_set“
arbeitet mit den äußeren JWE-Headern.auth_jwt_claim_set
arbeitet mit den verschachtelten JWS-Ansprüchen.$jwt_header_name -
Variablen enthalten die äußeren JWE-Header-Eigenschaften.$ jwt_claim_name
enthalten die verschachtelten JWS-Ansprüche.
Mit der folgenden Konfiguration erstellt und sendet NGINX Plus zusätzliche HTTP-Anforderungsheader an die Backend-Anwendung. Der Verschlüsselungsalgorithmus aus dem JWE-Header (die Variable $jwt_header_enc
) und der JWT-Subjektanspruch aus der JWS-Nutzlast (die Variable $jwt_claim_sub
) werden mit der ursprünglichen Anforderung per Proxy übermittelt. Dies bedeutet, dass Anwendungen die JWE-basierte Authentifizierung einfach durch die Verwendung von HTTP-Headern nutzen können, ohne dass kryptografischer Code oder Bibliotheken implementiert werden müssen.
Für Benutzer, die in Zero‑Trust‑Architekturen arbeiten, ermöglicht die folgende Konfiguration der Backend‑Anwendung, das JWS‑Token zu validieren, wie es in der Variable $jwt_payload
erfasst ist. Die Variable enthält die entschlüsselte Klartextversion des JWE-Chiffretextes. Wenn ein verschachteltes JWT vorhanden ist, kann das JWS als Trägertoken an die Back-End-Anwendung übergeben werden.
Im Wesentlichen optimieren verschachtelte JWTs Vorgänge und verbessern die Anwendungssicherheit, indem sie NGINX Plus ermöglichen, sichere Token gleichzeitig zu entschlüsseln und zu validieren, während gleichzeitig der mit „regulärem JWT“ signierte Token für Back-End-Anwendungen analysiert oder als Proxy verwendet wird.
NGINX Plus R24 führte Unterstützung für die symmetrische Verschlüsselung von Token mit dem AES-Standard ein. NGINX Plus R25 fügt Unterstützung für asymmetrische Verschlüsselung bei Verwendung von RSA-Schlüsselpaaren hinzu. Bei der asymmetrischen Kryptografie werden zur Ver- und Entschlüsselung unterschiedliche Schlüssel (öffentlich und privat) verwendet, die durch den RSA-Algorithmus (Rivest–Shamir–Adleman) mathematisch miteinander verknüpft sind. Dabei handelt es sich um den gleichen Mechanismus, der für die SSL/TLS-Verschlüsselung des HTTPS-Verkehrs zwischen Client und Server verwendet wird.
NGINX Plus R25 unterstützt RSA mit Optimal Asymmetric Encryption Padding (OEAP) als Schlüsselverwaltungsalgorithmus, ohne dass auf der NGINX Plus-Seite eine explizite Konfiguration erforderlich ist. Unterstützte Werte für den JWS- alg
-Header (Algorithmus) sind RSA-OAEP
, RSA-OAEP-256
, RSA-OAEP-384
und RSA-OAEP-512
.
Die folgende Konfiguration zeigt, dass zum Implementieren asymmetrischer Verschlüsselung für JWE lediglich die Angabe der JSON Web Key (JWK)-Datei erforderlich ist, die die privaten (Unwrap-) RSA-Schlüssel als Parameter für die Direktive „auth_jwt_key_file“
enthält (die Direktive „auth_jwt_key_request“
kann ebenfalls verwendet werden).
Die Nutzung verschachtelter JWTs bedeutet, dass die zugehörigen JWKs wahrscheinlich aus mehr als einer Quelle stammen. NGINX Plus R25 unterstützt mehrere auth_jwt_key_file-
und auth_jwt_key_request
-Direktiven im gleichen Kontext. NGINX Plus lädt Schlüssel aus allen angegebenen Quellen und sucht im kombinierten Schlüsselsatz nach dem passenden Verifizierungsschlüssel – äußerst nützlich bei der Arbeit mit einem JWS, das von einem externen Identitätsanbieter ausgestellt wurde und in einem JWE verschachtelt ist, bei dem die Verschlüsselung durch einen separaten Prozess erfolgte.
Diese Funktion verleiht NGINX Plus bei der Bereitstellung als API-Gateway noch mehr Flexibilität, Sicherheit und Leistung.
Wenn NGINX Plus als API-Gateway eingesetzt wird, ist es üblich, JWT-Ansprüche zu prüfen, um eine feinkörnige Zugriffskontrolle zu implementieren. Dies kann zu komplexen Konfigurationen führen. In früheren Versionen von NGINX Plus konnten Sie „if“
-Konfigurationsblöcke zum Auswerten von JWT-Ansprüchen verwenden, dieser Ansatz war jedoch etwas eingeschränkt und funktionierte nicht für verschlüsselte Token.
NGINX Plus R25 behebt diese Einschränkung, indem es eine native Möglichkeit bietet, während des JWT-Validierungsprozesses zusätzliche Prüfungen des Tokens durchzuführen. Die Direktive „auth_jwt_require“
fügt dem JWT-Validierungsprozess einen optionalen, anpassbaren Schritt hinzu. Es akzeptiert eine durch Leerzeichen getrennte Liste von Zeichenfolgen, die alle nicht leer und nicht gleich sein dürfen0
(Null), damit die JWT-Validierung erfolgreich ist. Dies verleiht dem JWT-Validierungsprozess enorme Flexibilität.
Der JWT-Standard schreibt nicht vor, welche Ansprüche obligatorisch sind. Sie können daher „auth_jwt_require“
verwenden, um die entsprechenden Ansprüche für jede Umgebung aufzulisten.
Die folgende Konfiguration stellt sicher, dass sowohl die exp-
als auch die sub
-Ansprüche in jedem Token vorhanden sind.
Sie können komplexere Anwendungsfälle konfigurieren, indem Sie Map-
Blöcke oder den Schlüssel-Wert-Speicher von NGINX Plus verwenden, um Boolesche Werte an die Direktive „auth_jwt_require“
zu übergeben. Sie können das NGINX JavaScript-Modul auch verwenden, um umfangreiche Authentifizierungslösungen wie zertifikatsgebundene Zugriffstoken für gegenseitiges TLS (mTLS) (definiert in RFC 8705 ) zu implementieren.
Die folgende Konfiguration führt sowohl die Client-Zertifikatauthentifizierung (mTLS) als auch die JWT-Validierung durch. Die Direktive „auth_jwt_require“
in Zeile 14 fordert die Auswertung der Variable „$thumbprint_match“
. Die JWT-Validierung ist nur erfolgreich, wenn sie einen Wert ungleich Null aufweist. Diese Variable wird durch Ausführen der in Zeile 2 aufgerufenen JavaScript-Funktion ausgewertet.
Hier ist der Code für die Validierungsfunktion
, die in Zeile 2 des vorherigen Snippets aufgerufen wurde:
Überwachung und Sichtbarkeit sind Eckpfeiler der Anwendungsleistung, Verfügbarkeit und Sicherheit. HTTP-Antwortcodes sind eine der wichtigsten Quellen für Einblicke in die Anwendungsintegrität. Die NGINX Plus-API verfolgt HTTP-Antwortcodes sowohl für Interaktionen zwischen NGINX und Clients als auch zwischen NGINX und Upstream-Servern. Die Anzahl wird auf den entsprechenden Registerkarten des Dashboards zur Live-Aktivitätsüberwachung von NGINX Plus angezeigt.
Frühere Versionen der NGINX Plus API aggregierten die Anzahl der HTTP-Antwortcodes nach Klasse ( 2xx
, 4xx
usw.). Nun werden Codes auch einzeln gezählt ( 200
,404
,503
, usw.). Dadurch erhalten Sie einen tieferen Einblick in das, was genau mit einer Anwendung passiert. Sie können zwischen Fehlern unterscheiden, die sehr unterschiedliche Ursachen haben, wie z. B. Spitzen bei fehlgeschlagenen Authentifizierungen (403
) und fehlender Inhalt (404
). Informationen zum Konfigurieren der Metrikerfassung finden Sie im NGINX Plus-Administratorhandbuch .
Die neueste Version der NGINX Plus API ( Version 7 ), die mit NGINX Plus R25 veröffentlicht wurde, enthält ein Codeobjekt
innerhalb des Antwortobjekts
, um das Zählen einzelner HTTP-Antwortcodes zu ermöglichen. Aggregierte Antworten sind weiterhin verfügbar und frühere Versionen der NGINX Plus-API – die das Codeobjekt
nicht enthalten – können weiterhin mit NGINX Plus R25 verwendet werden. Hier ist ein Beispiel für den neuen Satz von Kennzahlen:
$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq { "wird verarbeitet": 31, "Anfragen": 63192, "Antworten": { "1xx": 0, "2xx": 54368, "3xx": 8454, „4xx“: 330, "5xx": 9, "Codes": { "200": 54368, "302": 8454, "401": 30, "404": 200, "429": 100, "503": 9 }, "gesamt": 63161 }, "verworfen": 0, "empfangen": 693436, "gesendet": 13843478 }
Wichtiger Hinweis: Wenn NGINX Plus als Reverse-Proxy oder Load Balancer konfiguriert ist, erhöht das Zählen einzelner Codes die Speicherauslastung in der gemeinsam genutzten Speicherzone für jede Upstream-Gruppe. Wenn sich in der Upstream-Gruppe mehr als 20 Peers befinden, müssen Sie möglicherweise die Speichergröße erhöhen, wie mit der Zonendirektive
konfiguriert.
NGINX Plus R25 startet nicht, wenn die Upstream-Zonen nicht ausreichend bereitgestellt sind, was zu fehlgeschlagenen Upgrades führt.
Hier ist eine typische Konfiguration der gemeinsam genutzten Speicherzone für eine Upstream-Gruppe:
Bevor Sie auf NGINX Plus R25 aktualisieren, müssen Sie unbedingt die Speicherauslastung der vorhandenen Upstream-Zonen überprüfen. Stellen Sie dazu sicher, dass die NGINX Plus-API aktiviert ist, bevor Sie eine dieser Methoden verwenden:
Überprüfen Sie die Registerkarte „HTTP-Upstreams“ des Dashboards zur Liveaktivitätsüberwachung, wie in diesem Beispiel von demo.nginx.com , wo die Auslastung 54 % beträgt:
Verwenden Sie die NGINX Plus-API direkt vom Host aus, indem Sie den folgenden Befehl ausführen. Erste:
jq
API-
Variable auf den Speicherort fest, an dem die API-
Direktive aktiviert ist.$ API=http://localhost:8080/api; für i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; mache echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; fertig
Wenn die aktuelle Auslastung über 40 % liegt (wie im Screenshot), erhöhen Sie den zweiten Parameter (Größe) der Zonendirektive
um mindestens das 2,5-fache. Wir empfehlen beispielsweise, im obigen Konfigurationsausschnitt 64.000
auf 160.000
zu erhöhen.
Mutual TLS (mTLS) ist ein gängiges Authentifizierungsverfahren, bei dem die Identität von Client und Server überprüft wird. Mit NGINX Plus können Sie die Server in einer Upstream-Gruppe dynamisch und mit Variablen definieren. Das bedeutet, dass Sie möglicherweise auch in der Lage sein müssen, das von NGINX Plus verwendete TLS-Zertifikat dynamisch auszuwählen, um sich gegenüber diesen Upstream-Servern zu verifizieren.
NGINX Plus R25 erweitert die für mTLS verwendeten Konfigurationsdirektiven auf einen Backend-Server, um eine Variable zu akzeptieren, die das Zertifikat darstellt. Die Variable kann sich auf eines der folgenden beziehen:
„data“:
Dadurch kann NGINX Plus ein Zertifikat und einen privaten Schlüssel dynamisch auswählen – nützlich für moderne Anwendungsumgebungen, die ständigen Änderungen unterliegen. Sie können das Zertifikat und den privaten Schlüssel im Schlüssel-Wert-Speicher von NGINX Plus speichern. Dies erhöht die Sicherheit, da der private Schlüssel im Speicher und nicht auf der Festplatte gespeichert wird. Ein weiterer Anwendungsfall ist die automatisierte Zertifikatsrotation, bei der Sie einen API-Aufruf verwenden, um Zertifikate im Schlüssel-Wert-Speicher zu aktualisieren.
In der folgenden Konfiguration leitet NGINX Plus Anfragen basierend auf dem Hostnamen an verschiedene Upstream-Gruppen weiter. Die Proxy-Verbindung wird mithilfe von mTLS hergestellt und das entsprechende Client-Zertifikat für jeden Upstream wird dynamisch ausgewählt.
Die folgenden Anweisungen unterstützen das dynamische Laden von Zertifikaten für mTLS mit Upstream-Servern:
grpc_ssl_zertifikat
grpc_ssl_zertifikatsschlüssel
Proxy-SSL-Zertifikat
Proxy-SSL-Zertifikatschlüssel
uwsgi_ssl_zertifikat
uwsgi_ssl_zertifikatsschlüssel
Einer der Grundpfeiler der NGINX-Philosophie ist die kontinuierliche Verbesserung, insbesondere im Hinblick auf die Sicherheit. Wir nutzen alle verfügbaren Ressourcen, darunter die Zusammenarbeit mit Sicherheitsforschern, die Integration der branchenführenden Sicherheitstechnologien von F5 in unsere Produkte und interne Entwicklungsbemühungen.
Als Beispiel für Letzteres führt NGINX Plus R25 mehrere zusätzliche Prüfungen von HTTP-Anfragen durch, um Ihre Anwendungen vor potenziellen Angriffen, wie etwa Anforderungsschmuggel , zu schützen. Unter diesen Bedingungen wird ein Fehler zurückgegeben:
Transfer-Encoding-
Header„Transfer-Encoding“
und „Content-Length“
sind beide vorhandenHost-
Header enthält Leerzeichen oder SteuerzeichenCONNECT
-Methode wird verwendetDarüber hinaus werden die folgenden Zeichen in einer Proxied-URI jetzt immer maskiert: "
, <
, >
, \
, ^
, `
, {
, |
, }
.
Bitte beachten Sie, dass es sich bei diesen Änderungen um proaktive Sicherheitsverbesserungen handelt und nicht um Reaktionen auf bekannte Sicherheitslücken.
NGINX Plus verwendet obligatorische Integritätsprüfungen, um sicherzustellen, dass neue Server, die zu Upstream-Gruppen hinzugefügt werden, getestet und fehlerfrei sind, bevor Clientanforderungen an sie weitergeleitet werden. In NGINX Plus R23 und früheren Versionen galten Upstream-Server nach einem Neuladen der Konfiguration als fehlerhaft, unabhängig von ihrem Status vor dem Neuladen. Dies hatte zur Folge, dass NGINX Plus keine Anfragen an einen Server schickte, bis die erste obligatorische Prüfung bestanden war.
NGINX Plus R24 führte für HTTP-Anwendungen die optionale Persistenz des obligatorischen Integritätsprüfstatus über Neuladevorgänge hinweg ein. Wenn die letzte obligatorische Integritätsprüfung vor einem Neuladen erfolgreich war, kann NGINX Plus sofort Anfragen an einen Server senden, anstatt auf den Erfolg einer obligatorischen Integritätsprüfung nach dem Neuladen warten zu müssen.
NGINX Plus R25 erweitert diese Funktionalität auf TCP/UDP-Anwendungen (innerhalb des Stream-
Kontexts). Fügen Sie wie bei HTTP den persistenten
Parameter zusammen mit dem obligatorischen
Parameter zur Direktive health_check
hinzu.
Das NGINX JavaScript-Modul (njs) wurde mit mehreren Fehlerbehebungen und einigen Funktionsverbesserungen, die die Kompatibilität mit JavaScript ES6 stärken, auf Version 0.6.2 aktualisiert.
let
und const
NGINX JavaScript unterstützt jetzt die Deklaration von Variablen mit Gültigkeitsbereich mit den Schlüsselwörtern let
und const
. Frühere Versionen von NGINX Plus und njs unterstützten nur das Schlüsselwort var
zum Deklarieren und Zuweisen von Variablen. Dabei wurden keine Variablen berücksichtigt, die auf den Umfang einer bestimmten Blockanweisung
beschränkt sind, die jedoch erforderlich sind, um die Komplexität zu bewältigen, die häufig entsteht, wenn verschiedene Projekte, Programmiersprachen und Entwicklungsteams an gemeinsamen Codebasen oder Bibliotheken zusammenarbeiten.
JavaScript ES6 bietet die Schlüsselwörter let
und const
zum Definieren von Variablen mit Gültigkeitsbereich:
Let
-Variablen sind auf den Gültigkeitsbereich einer Blockanweisung
oder eines Ausdrucks beschränkt, auf den sie angewendet werden. Im Gegensatz dazu deklariert das Schlüsselwort var
eine Variable global oder lokal für eine ganze Funktion, unabhängig vom Blockbereich.Konstantenvariablen
haben einen Blockbereich, ähnlich wie Variablen, die mit dem Schlüsselwort let
deklariert werden. Der Wert einer Konstanten kann nicht durch Neuzuweisung geändert und nicht neu deklariert werden.Promise
-KonstruktormethodenDurch die Ergänzung der Konstruktormethoden Promise.all()
, Promise.allSettled()
, Promise.any()
und Promise.race()
unterstützt njs jetzt den vollständigen Satz an Konstruktormethoden, die im JavaScript ES6-Standard definiert sind.
Wenn Sie NGINX Plus verwenden, empfehlen wir Ihnen dringend, so bald wie möglich auf NGINX Plus R25 zu aktualisieren. Sie erhalten außerdem mehrere zusätzliche Fehlerbehebungen und Verbesserungen und NGINX kann Ihnen helfen, wenn Sie ein Support-Ticket erstellen müssen.
Wenn Sie NGINX Plus noch nicht ausprobiert haben, empfehlen wir Ihnen, es auszuprobieren – für Sicherheit, Lastausgleich und API-Gateway oder als vollständig unterstützten Webserver mit erweiterten Überwachungs- und Verwaltungs-APIs. Sie können noch heute mit einer kostenlosen 30-Tage-Testversion beginnen.
„Dieser Blogbeitrag kann auf Produkte verweisen, die nicht mehr verfügbar und/oder nicht mehr unterstützt werden. Die aktuellsten Informationen zu verfügbaren F5 NGINX-Produkten und -Lösungen finden Sie in unserer NGINX-Produktfamilie . NGINX ist jetzt Teil von F5. Alle vorherigen NGINX.com-Links werden auf ähnliche NGINX-Inhalte auf F5.com umgeleitet."