Bei der Arbeit an einem regulären Ausdruck (Regex) für die Verwendung mit NGINX kam mir eine Idee, wie sich eine Regex ganz einfach innerhalb einer tatsächlichen NGINX-Konfiguration testen lässt. (Der Regex-Tester funktioniert für NGINX Open Source und NGINX Plus gleichermaßen. Der besseren Lesbarkeit halber verwende ich in diesem Beitrag einfach die Bezeichnung NGINX.)
Die Unterstützung regulärer Ausdrücke ist eine der leistungsstarken Funktionen von NGINX. Allerdings können reguläre Ausdrücke komplex und schwer korrekt zu erstellen sein, insbesondere wenn Sie nicht regelmäßig damit arbeiten. NGINX ermöglicht reguläre Ausdrücke in mehreren Bereichen einer Konfiguration, beispielsweise in Locations, Maps, Rewrites und Servernamen. Der hier beschriebene Tester ist für reguläre Ausdrücke in Locations und Maps vorgesehen.
Es gibt andere kostenlose Online-Tester für reguläre Ausdrücke, die sich für die meisten regulären Ausdrücke gut eignen. NGINX verwendet jedoch einige nicht standardmäßige, für Webanwendungen optimierte Kurzformen. Beispielsweise müssen Sie den Schrägstrich (/) in einem URI nicht wie bei einem standardmäßigen regulären Ausdruck maskieren. Wenn Sie einen regulären Ausdruck in einer Map verwenden, geben Sie außerdem an, welcher Wert bei einer Übereinstimmung gesetzt werden soll. Bei anderen Testern für reguläre Ausdrücke müssen Sie möglicherweise den regulären Ausdruck anpassen oder im Fall einer Map ableiten, welcher Wert gesetzt wird. Darüber hinaus ist es immer von Vorteil, einen regulären Ausdruck mit der tatsächlich verwendeten Regex-Engine in der tatsächlichen Umgebung testen zu können.
Hinweise:
- NGINX verwendet Perl-kompatible reguläre Ausdrücke (PCRE). Dieser Beitrag setzt grundlegende Kenntnisse sowohl von NGINX als auch von regulären Ausdrücken voraus. Die Erklärung, wie reguläre Ausdrücke erstellt werden, würde den Rahmen dieses Beitrags sprengen. Leider können wir daher im Kommentarbereich keine weiteren Fragen dazu beantworten. Zahlreiche Websites bieten Tools oder Dokumentationen zum Erstellen regulärer Ausdrücke an. Zwei davon, die wir als hilfreich empfunden haben, sind:
- Der Tester verarbeitet reguläre Ausdrücke in zwei Kontexten – in
map{}-Blöcken und HTTP-location{}-Blöcken – und im Folgenden wird kurz erläutert, wie reguläre Ausdrücke im jeweiligen Fall funktionieren. Eine Erklärung dazu, wie NGINX reguläre Ausdrücke in allen Kontexten verarbeitet, würde den Rahmen dieses Beitrags sprengen. Weitere Informationen finden Sie in unserer Dokumentation:- Systemzustandsprüfungen:
- HTTP – nginx.org und NGINX Plus-Administratorhandbuch
- TCP – nginx.org und NGINX Plus-Administratorhandbuch
- UDP – nginx.org und NGINX Plus Administratorhandbuch
location{}-Blöcke – nginx.org und NGINX Plus-Administratorhandbuchmap{}-Blöcke – nginx.org- URI-Umschreibungen – nginx.org und NGINX Plus-Administratorhandbuch
- Namen virtueller Server – nginx.org und NGINX Plus-Administratorhandbuch
- Systemzustandsprüfungen:
- Der Tester ist bewusst so einfach wie möglich konzipiert und dient nur einem Zweck: Er testet die vom Benutzer eingegebenen regulären Ausdrücke mit der tatsächlichen NGINX-Regex-Engine für Maps und HTTP-Standorte. Daher müssen Sie nur ein Minimum an Informationen angeben, um eine funktionsfähige NGINX-Konfiguration zu erstellen. Wir planen nicht, weitere Funktionen hinzuzufügen (etwa eine Validierung des regulären Ausdrucks vor dem Test), da dies dem Leitprinzip der Einfachheit widersprechen würde. Fehler beheben wir selbstverständlich gerne; melden Sie diese bitte auf der Registerkarte Issues in unserem GitHub-Repository.
Übersicht
Bevor wir uns mit den Details des Regex-Testers befassen, wollen wir zunächst erläutern, wie reguläre Ausdrücke in NGINX-Standorten und -Maps verwendet werden können.
Locations
Reguläre Ausdrücke in NGINX-location{}-Blöcken haben die folgende Form:
location regex {
#...
}Beispielsweise verarbeitet ein location{}-Block mit dem folgenden regulären Ausdruck alle PHP-Anfragen mit einem URI, der auf myapp/Dateiname.php endet, etwa /test/myapp/hello.php und /myapp/hello.php. Das Sternchen nach der Tilde (~*) bewirkt, dass beim Abgleich die Groß- und Kleinschreibung nicht berücksichtigt wird.
location ~* /myapp/.+\.php$ {
#...
}NGINX und der Regex-Tester unterstützen positionale Erfassungsgruppen in location{}-Blöcken. Im folgenden Beispiel erfasst die erste Gruppe alles vor dem Namen der PHP-Datei und die zweite den Namen der PHP-Datei:
location ~* (.*/myapp)/(.+\.php)$ {
#...
}Für den URI /myapp/hello.php wird die Variable $1 auf /myapp und $2 auf hello.php gesetzt.
NGINX unterstützt auch benannte Erfassungsgruppen:
location ~* (?<begin>.*myapp)/(?<end>.+\.php)$ {
#...
}In diesem Fall wird die Variable $begin auf /myapp und $end auf hello.php gesetzt.
Der Regex-Tester unterstützt benannte Erfassungsgruppen, behandelt sie in seiner Ausgabe jedoch wie positionale Erfassungsgruppen und zeigt ihre Ordnungsnummern anstelle ihrer Namen an.
Maps
NGINX-map{}-Blöcke, die reguläre Ausdrücke verwenden, haben folgende Form:
map variable-to-test variable-to-set {
regex1 value-to-set-if-match;
regex2 value-to-set-if-match;
#...
regexN value-to-set-if-match;
default value-to-set-if-no-match;
}Dieser map{}-Block setzt beispielsweise die Variable $isphp auf 1, wenn der URI (wie in der Variable $uri gespeichert) auf .php endet, andernfalls auf 0 (bei der Übereinstimmung wird zwischen Groß- und Kleinschreibung unterschieden):
map $uri $isphp {
~\.php$ 1;
default 0;
}Bei Maps unterstützen NGINX und der Regex-Tester sowohl positionale als auch benannte Erfassungsgruppen.
Beispielsweise setzen die beiden folgenden Maps die Variable $fileext auf den Wert der Dateierweiterung, der in diesem Beispiel auch als $1 erfasst wird:
map $uri $fileext {
~*.+\.(.+)$ $1;
default '';
}Und als „$ext“ in diesem Beispiel:
map $uri $fileext {
~*.+\.(?<ext>.+)$ $ext;
default '';
}Sie können den Regex-Tester für map{}-Blöcke sowohl im http{}- als auch im stream{}-Kontext verwenden, da Syntax und Verhalten von Maps in beiden Kontexten identisch sind. Beachten Sie jedoch, dass Sie nur den map{}-Block aus der Ausgabe des Testers verwenden können, wenn sich Ihre Map im stream{}-Kontext befindet. Weitere Informationen finden Sie im nachstehenden Hinweis.
Der Tester für reguläre Ausdrücke
Der Regex-Tester ist in einem Docker-Container mit NGINX und NGINX Unit implementiert. NGINX Unit stellt zwei Varianten einer PHP-Seite bereit: eine für reguläre Ausdrücke in location{}-Blöcken und eine für reguläre Ausdrücke in map{}-Blöcken. Auf den beiden Seiten werden die Benutzer zu unterschiedlichen Eingaben aufgefordert:
- Standortseite:
- Der reguläre Ausdruck
- Groß-/Kleinschreibung
- Der URI
- Kartenseite:
- Der reguläre Ausdruck
- Groß- und Kleinschreibung
- Der zu prüfende Wert (der Wert der Variablen, die als erster Parameter an die
map-Direktive übergeben wird) - Der Wert, der in der als zweiter Parameter der
map-Direktive angegebenen Variablen festgelegt werden soll
Nachdem Sie die Informationen eingegeben haben, klicken Sie auf die Schaltfläche „Test“. Der Tester generiert die erforderliche NGINX-Konfigurationsdatei, lädt die Konfiguration neu und sendet eine Anfrage, um den regulären Ausdruck zu testen. Anschließend werden die Ergebnisse angezeigt und geben an, ob eine Übereinstimmung gefunden wurde. Ist dies der Fall, werden auf der Seite „Location Tester“ die Werte der Erfassungsgruppen und auf der Seite „Map Tester“ der von der Map festgelegte Wert angezeigt.
Beispiel für die Location-Seite
Dieses Beispiel zeigt die Ergebnisse einer Prüfung des regulären Ausdrucks ohne Berücksichtigung der Groß- und Kleinschreibung (.*myapp)/(.+\.php)$ anhand des URI /myapp/hello.php:

Beispiel für eine Kartenseite
Dieses Beispiel zeigt die Ergebnisse einer Prüfung des regulären Ausdrucks ohne Berücksichtigung der Groß- und Kleinschreibung .+\.(?<ext>.*)$ anhand des Werts /myapp/hello.php, wobei die benannte Erfassungsgruppe $ext als festzulegender Wert verwendet wird:

Hinweis: Wenn sich Ihre Map im stream{}-Kontext befindet, können Sie in Ihrer Konfiguration nur den map{}-Block aus der Ausgabe verwenden. Der server{}-Block ist ungültig, da er einen location{}-Block enthält, der im stream{}-Kontext nicht unterstützt wird.
Fazit
Wie Sie sehen, ist die NGINX-Konfiguration recht kurz und einfach. Die eigentliche Arbeit übernimmt die PHP-Seite: Sie generiert anhand der vom Benutzer eingegebenen Werte die erforderliche NGINX-Konfigurationsdatei, lädt NGINX neu, sendet eine Anfrage an NGINX und zeigt die Ergebnisse an.
Sie können den Regex-Tester selbst ausprobieren: Der gesamte Code ist in unserem GitHub-Repository verfügbar (https://github.com/nginxinc/NGINX-Demos/tree/master/nginx-regex-tester).
Damit Sie den Regex-Tester schnell und einfach in Betrieb nehmen können, sind alle erforderlichen Dateien enthalten. Um das Docker-Image zu erstellen und den Container zu bauen, führen Sie einfach folgenden Befehl aus:
$ docker-compose up -dRufen Sie anschließend in Ihrem Browser http://Docker-Host/regextester.php auf.
Ich hoffe, dass Ihnen der Tester bei der Arbeit mit regulären Ausdrücken hilft und Ihnen einen Eindruck von der Leistungsfähigkeit, Flexibilität und Einfachheit von NGINX vermittelt.
Um den Regex-Tester mit NGINX Plus auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über den Autor

Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.