Nginx-Server- und Location-Block-Auswahlalgorithmen: Übersicht

Einführung

Nginx gehört zu den weltweit beliebtesten Webserver-Optionen. Er ist in der Lage, eine Vielzahl von gleichzeitigen Client-Verbindungen erfolgreich zu bewältigen. Gleichzeitig fungiert er als Mail-, Web- oder Reverse-Proxy-Server.

Diese Anleitung soll die Methoden hinter den Kulissen skizzieren, die steuern, wie Nginx Client-Anfragen verarbeitet. Wir werden das Server- und Location-Block-Design entmystifizieren sowie erklären, wie sich die scheinbare Unvorhersehbarkeit bei der Bearbeitung von Anfragen am besten reduzieren lässt.

Zuerst einmal finden Sie hier eine umfassende Anleitung dazu, wie Sie Nginx auf Ihrem Ubuntu-Server installieren. Und nun lassen Sie uns beginnen!

Block-Konfiguration mit Nginx

Der logische Ansatz von Nginx besteht darin, die für verschiedene Zwecke vorgesehenen Konfigurationen in separate, logischere Inhaltsblöcke zu sortieren. Diese befinden sich in einer hierarchischen Struktur. Wenn ein Client eine Anfrage stellt, initiiert Nginx einen Prozess, mit dem bestimmt wird, welche dieser Konfigurationsblöcke am besten geeignet sind, um diese Anfrage zu bearbeiten. Wir werden uns auf diesen Entscheidungsprozess konzentrieren.

Die primären Blöcke, die wir besprechen werden, sind server-Blöcke und location-Blöcke. Server-Blöcke sind eine Teilmenge der von Nginx erstellten Konfigurationen, die definieren, welcher virtuelle Server für die Bearbeitung eines bestimmten Anfragetyps zuständig ist. Sie basieren meist auf der IP-Adresse, dem Domänennamen oder dem Port der eingehenden Anfrage. Administratoren konfigurieren mehrere Server-Blöcke. Anschließend müssen sie entscheiden, welche der Verbindungen die Anfrage bearbeiten soll.

Location-Blöcke befinden sich innerhalb der Server-Blöcke. Sie entscheiden darüber, wie und welche Ressourcen Sie nutzen können, um die eingehenden Anfragen an ihren jeweiligen übergeordneten Server zu bearbeiten. Dieses Modell ist äußerst flexibel. Der URI-Bereich kann so konfiguriert werden, dass diese Blöcke so genutzt werden, wie es der Administrator für am besten hält.

Mit Nginx entscheiden, welcher Block welche Anfrage verarbeitet

Nginx ermöglicht die Definition mehrerer Server-Blöcke. Sie alle fungieren als unterschiedliche virtuelle Webserver. Daher muss es eine Methode geben, die festlegt, welcher Server bestimmte eingehende Anfragen bearbeitet. Dies geschieht, indem durch ein System definierter Prüfungen die beste Übereinstimmung für die Anfrageleistung ermittelt wird.

Nginx befasst sich in erster Linie mit zwei Hauptdirektiven für Server-Blöcke: listen und server_name.

Mögliche Übereinstimmungen mit der „Listen“-Direktive finden

Das Erste, was Nginx auswertet, sind der Port und die IP-Adresse der Anfrage. Anschließend gleicht es diese mit der listen-Direktive jedes Servers ab. Dieses Parsen der Serverliste hilft dabei, genau die Server-Blöcke zu isolieren, die die betreffende Anfrage auflösen können.

Normalerweise definiert die listen-Direktive den Port und die IP-Adresse, für deren Beantwortung ein bestimmter Server-Block zuständig ist. Ein Server-Block, der keine listen-Direktive enthält, erhält standardmäßig die listen-Parameter 0.0.0.0:80. Wenn Nginx von einem normalen Benutzer ohne Root-Rechte ausgeführt wird, ist der listen-Parameter als 0.0.0.0:8080 definiert. Das bedeutet, dass unabhängig von der Schnittstelle, wenn die Blöcke von Port 80 kommen, so definierte Blöcke darauf reagieren. Dieser Standardwert fällt jedoch bei der Auswahl eines Servers nicht stark ins Gewicht.

Sie können die listen-Direktive wie folgt konfigurieren:

• Eine einzelne IP-Adresse, die auf dem Standardport (80) auf Anfragen lauscht.
• Ein einzelner Port, der auf jeder Schnittstelle an diesem Port lauscht.
• Eine Kombination aus Port und IP-Adresse.
• Ein festgelegter Unix-Socket-Pfad (diese Option hat nur Auswirkungen, wenn Anfragen über verschiedene Server weitergeleitet werden).

Nginx wendet eine Reihe von Regeln an, wenn entschieden wird, an welchen Server-Block eine Anfrage gesendet wird. Die Regeln hängen von der jeweiligen Konfiguration der listen-Direktive ab. Sie lauten wie folgt:

• Wenn eine listen-Direktive unvollständig ist, erhalten die fehlenden Teile ihre Standardwerte. Dies bedeutet, dass die IP-Adresse und der Port zwangsweise mit Standardwerten ergänzt werden, um die Anfrage zu verarbeiten.
  • In diesem Fall verwendet ein Block, der keine listen-Direktive enthält, den Standardwert 0.0.0.0:80.
  • Ein Block, dem ein Port fehlt und der eine IP-Adresse von 111.111.111.111 hat, wird zu 111.111.111.111:80.
  • Wenn keine IP-Adresse vorhanden ist, übernimmt ein Block mit Port 8888 die Standard-IP-Adresse, um 0.0.0.0:8888 zu erstellen.
• Nachdem die IP-Adresse und der Port bestimmt wurden, sucht Nginx nach Server-Blöcken, die als Übereinstimmung für diesen Port angeboten werden.
• Wenn nur eine spezifische Übereinstimmung gefunden wird, ist dies der Server-Block. Wenn mehrere Blöcke infrage kommen, greift Nginx auf die server_name-Direktive zurück, um den genauen Server-Block weiter einzugrenzen.

Nginx greift nur dann auf die Auswertung der server_name-Direktive zurück, wenn kein Server-Block mit dem exakten Spezifitätsgrad aus der listen-Direktive gefunden wurde. Wenn sich example.com auf Port 80 mit der IP 192.168.1.10 befindet, ist der erste Block in diesem Beispiel immer derjenige, der die Anfrage verarbeitet. Dies ist unabhängig davon, was in der server_name-Direktive steht:

Wenn es mehr als nur einen qualifizierten Server-Block mit einer übereinstimmenden Spezifität gibt, wird die server_name-Direktive berücksichtigt.

Mögliche Übereinstimmungen mit der „Server_Name“-Direktive finden

Wenn die listen-Direktiven gleich spezifisch sind, prüft Nginx den Header des „Host“ der Anfrage’s. Dies ist ein Wert, der die IP der Domain enthält, die der Client ursprünglich erreichen wollte. Nginx verwendet die server_name-Direktive innerhalb jedes noch qualifizierten Server-Block-Kandidaten. Es führt diese Auswertungen basierend auf einer Formel durch. Diese lautet wie folgt:

• Der erste Versuch von Nginx besteht darin, einen Block mit einem server_name zu identifizieren, der genau mit dem Wert des „Host“-Headers in der Anfrage übereinstimmt. Wenn er ihn findet, ist der Block mit der genauen Übereinstimmung derjenige, der die Anfrage bedient. Falls er mehrere Blöcke findet, wählt er den ersten auf der Liste.
• Wenn keine genauen Übereinstimmungen vorliegen, versucht Nginx, über server_name den Server-Block zu finden, der unter Verwendung von *, einer Wildcard am Anfang des Server-Block-Namens in der Konfiguration, übereinstimmt. Wenn mit dieser Methode einer gefunden wird, bedeutet dies, dass der Server-Block bestimmt wurde. Wenn mehr als eine Übereinstimmung gefunden wird, ist die längste Übereinstimmung diejenige, die die Anfrage erfüllt.
• Ohne eine passende Wildcard versucht Nginx, einen Server-Block mit einer passenden nachgestellten Wildcard zu finden. Mit anderen Worten, dies ist ein Servername mit einem * in der Konfiguration. Wenn einer gefunden wird, wird er für die Anfrage verwendet. Wenn Sie hingegen mehrere finden, verwendet Nginx erneut die längste Übereinstimmung.
• Falls nach beiden Wildcard-Versuchen immer noch keine Übereinstimmungen vorliegen, wertet Nginx diejenigen Server-Blöcke aus, die den server_name mithilfe von regulären Ausdrücken definieren (gekennzeichnet durch ein ~ vor dem Namen). Die erste Instanz von server_name mit einem Ausdruck, der dem des „Host“-Headers entspricht, wird als Server-Block für die Verarbeitung der Anfrage herangezogen.
• Wenn an diesem Punkt immer noch keine Übereinstimmungen vorliegen, verwendet Nginx den Standard-Server-Block für diese Kombination aus Port und IP-Adresse.

Jede Kombination aus Port und IP-Adresse hat einen zugewiesenen Server-Block. Dieser wird verwendet, wenn die Regeln zur Bestimmung des geeigneten Server-Blocks für die Anfrageverarbeitung erfolglos sind. Dies ist der erste Block in der Konfiguration, der eine default_server-Option in der listen-Direktive enthält (er würde den ursprünglich gefundenen Algorithmus überschreiben). Jede IP-Adress-/Port-Kombination kann maximal eine default_server-Einstellung haben.

Beispiele für die Auswahl von Server-Blöcken

Wenn der definierte server_name exakt mit dem Wert des „Host“-Headers übereinstimmt, wird dieser Server-Block für die Anfrageverarbeitung ausgewählt. Das folgende Beispiel zeigt einen „Host“-Header der Anfrage, der als „host1.example.com“ angegeben ist. In diesem Fall wird der zweite Server ausgewählt:

Ohne eine genaue Übereinstimmung prüft Nginx, ob der server_name mit einer Wildcard existiert. Wenn nicht, wird die längste Übereinstimmung ausgewählt, die mit einer Wildcard beginnt. Im Folgenden ist „www.example.org“ im „Host“-Header enthalten. Das bedeutet, dass der zweite Block ausgewählt wird:

Ohne eine Übereinstimmung, die mit dem Platzhalter beginnt, fährt Nginx mit der Überprüfung auf einen nachgestellten Platzhalter fort. Die längste Übereinstimmung, die mit dem Platzhalter endet, wird für die Verarbeitung der Anfrage ausgewählt. In diesem Fall lautet der „Host“-Header „www.example.com“, daher wird der dritte Server-Block ausgewählt:

Wenn immer noch keine Übereinstimmungen vorliegen, versucht Nginx, server_name-Direktiven mithilfe von regulären Ausdrücken abzugleichen. Der erste dieser Ausdrücke wird für die Verarbeitung der Anfrage ausgewählt. Wenn der „Host“ „www.example.com“ ist, ist der zweite Server-Block die Wahl, um die Anfrage zu bearbeiten:

Wenn immer noch keine Übereinstimmung gefunden wurde, geht die Anfrage an die Kombination aus IP-Adresse und Port mit dem entsprechenden eingerichteten Standard-Server.

Abgleich von Location-Blöcken

Nginx muss außerdem einen Algorithmus festlegen, nach dem entschieden wird, welcher Location-Block auf dem Server für die Beantwortung einer Anfrage zuständig ist.

Syntax für Location-Blöcke

Bevor wir erklären, wie Nginx entscheidet, welchen Location-Block es für die Bearbeitung von Anfragen bestimmt, werden wir die Syntax in Location-Block-Definitionen überprüfen. Wie bereits erwähnt, befinden sich Location-Blöcke in Server-Blöcken (und anderen Location-Blöcken). Ihr Zweck ist es, Entscheidungen darüber zu treffen, wie die Anfrage-URI verarbeitet werden soll. Die URI ist der Teil der Anfrage, der nach der IP-Adresse und dem Port oder dem Domainnamen in der Anfrage steht.

Location-Blöcke sehen typischerweise so aus:

Nginx prüft die URI der Anfrage gegen den location_match. Ob der obige Modifikator vorhanden ist oder nicht, bestimmt die Art und Weise, wie Nginx versucht, die Blöcke abzugleichen. Je nach Modifikator werden die Location-Blöcke nach den folgenden Regeln interpretiert:

• Keine Modifikatoren: Ohne Modifikatoren wird die Location als Präfix-Übereinstimmung interpretiert. Dies bedeutet, dass die angegebene Location mit dem Anfang der URI der Anfrage abgeglichen wird, um eine korrekte Übereinstimmung zu ermitteln.
• =: Das Gleichheitszeichen bedeutet, dass dieser Block als Übereinstimmung betrachtet wird, solange die URI der Anfrage exakt mit der angegebenen Location übereinstimmt.
• ~: Der Tilde-Modifikator bedeutet, dass der Abgleich des Location-Blocks die Groß-/Kleinschreibung berücksichtigt.
• ~*: Die Kombination aus einer Tilde und einem Sternchen-Modifikator bedeutet, dass der Location-Block bei der Suche nach einer Übereinstimmung die Groß-/Kleinschreibung ignoriert.
• ^~: Wenn dem Tilde-Modifikator ein Zirkumflex (Caret) vorangestellt ist, findet kein Abgleich mit regulären Ausdrücken statt, solange dieser Block als beste Nicht-Regulärer-Ausdruck-Übereinstimmung ausgewählt wird.

Beispiele für die Syntax von Location-Blöcken

Um ein Beispiel für den Präfix-Abgleich zu zeigen: Der Location-Block wird ausgewählt, um auf eine URI einer Anfrage in der Form /site, /site/page1/index.html oder /site/index/html zu antworten:

Für die Zwecke dieser Demonstration des erforderlichen URI-Abgleichs wird der Block immer verwendet, um auf URI-Anfragen in der Form /page1 zu antworten, und nicht auf die Anfrage-URI /page1/index.html. Wenn dies der ausgewählte Block ist und er die Anfrage über eine Index-Seite erfüllt, wird der eigentliche Handler der Anfrage intern an eine andere Location weitergeleitet:

Beispielsweise könnte für eine Location, die mit einem case-sensitiven Ausdruck interpretiert werden muss, der folgende Block keine Anfragen für /FLOWER.PNG verarbeiten. Er wird jedoch Anfragen für /tortoise.jpg verarbeiten:

Betrachten Sie als Nächstes einen Block, der einen case-insensitiven Abgleich ermöglicht, ähnlich dem obigen. In diesem Fall könnte der Block sowohl //tortoise.jpg als auch /FLOWER.PNG:

Die letzte Variante ist eine, bei der ein Block den Abgleich mit regulären Ausdrücken verhindert, wenn festgestellt wird, dass er die optimale Nicht-Regulärer-Ausdruck-Übereinstimmung ist. Dieser kann Anfragen für /costumes/ninja.html verarbeiten:

Um es auf den Punkt zu bringen: Die Modifikatoren bestimmen die Art und Weise, wie Location-Blöcke ermittelt werden. Dies sagt uns jedoch nicht, welchen Entscheidungsalgorithmus Nginx verwendet, um den Location-Block zu identifizieren, an den eine Anfrage gesendet werden soll. Dem widmen wir uns als Nächstes.

Auswählen der Location, die Anfragen durch Nginx verarbeitet

Die Methode, mit der Nginx den Location-Block auswählt, der eine Anfrage verarbeitet, ähnelt der Auswahl von Server-Blöcken. Mit anderen Worten: Nginx ermittelt den optimalen Ort für jede Anfrage, indem es einen Prozess durchläuft. Um Nginx präzise und entsprechend zu konfigurieren, ist es unerlässlich, diesen Prozess zu verstehen.

Unter Berücksichtigung der zuvor behandelten Location-Deklarationen nutzt Nginx in ähnlicher Weise potenzielle Location-Kontexte, indem es die Eignung für jede Location prüft und sie mit der URI einer  bestimmten Anfrage vergleicht. Dabei wendet es den folgenden Algorithmus an:

• Zuerst prüft Nginx alle Location-Typen, die keinen regulären Ausdruck enthalten. Dies geschieht, indem nach allen präfixbasierten Übereinstimmungen gesucht wird. Dazu gleicht es die Location mit der vollständigen URI der Anfrage ab.
• Nginx beginnt mit der Suche nach einer exakten Übereinstimmung. Sobald ein Location-Block identifiziert wird, der den Modifikator = verwendet, wird er mit der angeforderten URI verglichen. Wenn beide exakt übereinstimmen, wird dieser Location-Block sofort ausgewählt, um die Anfrage direkt vor Ort zu bearbeiten.
• Wenn keine Locations exakt mit dem Modifikator = übereinstimmen, fährt Nginx mit der Auswertung von Präfixen fort, die nicht exakt sind. Sobald die Location mit dem längsten übereinstimmenden Präfix für die URI der Anfrage ermittelt wurde, führt Nginx die folgenden Auswertungen durch:
  • Wenn die Location mit der längsten Präfix-Übereinstimmung den Modifikator ^~ verwendet, wird diese Location sofort ausgewählt.
  • Wenn die Location mit dem längsten Präfix nicht den Modifikator ^~ verwendet, wird die Übereinstimmung von Nginx vorübergehend gespeichert, damit sich der Fokus der Suche verschieben kann.
• Sobald die Location mit der längsten Präfix-Übereinstimmung gefunden und gespeichert ist, wechselt Nginx zur Auswertung von Locations mit regulären Ausdrücken. Diese umfassen sowohl Übereinstimmungen mit als auch ohne Berücksichtigung der Groß-/Kleinschreibung. Wenn die am längsten übereinstimmende Präfix-Location reguläre Locations in sich enthält, ordnet Nginx die Liste neu, um diese weiter oben in der Liste der Locations zu platzieren. Der erste Ausdruck aus der neu sortierten Liste, der mit der URI einer Anfrage übereinstimmt, wird als Location für die Bearbeitung der Anfrage ausgewählt.
• Wenn keine regulären Ausdrücke gefunden werden, die die Anfrage-URI erfüllen, wird die zuvor gespeicherte Location ausgewählt, um die Anfrage zu verarbeiten.

Standardmäßig bevorzugt Nginx Übereinstimmungen mit regulären Ausdrücken gegenüber bevorzugten Präfix-Übereinstimmungen. Es wertet jedoch zuerst Präfix-Locations aus, sodass der Administrator diese Tendenz mit den Modifikatoren = und ^~ außer Kraft setzen kann.

Eine weitere wichtige Erkenntnis ist, dass Präfix-Locations in der Regel auf der spezifischsten, am längsten gefundenen Übereinstimmung basieren, während die Prüfung regulärer Ausdrücke gestoppt wird, sobald die erste Übereinstimmung identifiziert ist. Dies bedeutet, dass die Positionierung innerhalb der Konfiguration echte Auswirkungen auf Locations mit regulären Ausdrücken hat.

Ein letzter Punkt ist, dass die Übereinstimmungen mit regulären Ausdrücken innerhalb der Übereinstimmung mit dem längsten Präfix bei den Location-Auswertungen von Nginx im Wesentlichen die Warteschlange überspringen. Diese werden an den Anfang der Liste gesetzt und vor anderen regulären Ausdrücken ausgewertet.

Wann kommt es bei der Auswertung von Location-Blöcken zu Sprüngen zu anderen Locations?

Normalerweise wird eine Anfrage, sobald sie bewertet und ein Location-Block zu ihrer Bearbeitung ausgewählt wurde, vollständig in diesem Kontext behandelt. Dies bedeutet, dass nur die vererbten Direktiven und ausgewählten Locations für die Verarbeitung der Anfrage ausschlaggebend sind, ohne jeglichen Einfluss von benachbarten Location-Blöcken.

Obwohl dies eine allgemeine Richtlinie ist, die ein vorhersehbares Design von Location-Blöcken ermöglicht, können manchmal auch bestimmte Direktiven innerhalb der Location eine neue Suche auslösen. Mit anderen Worten: Die Regel „nur ein Location-Block“ hat einige Ausnahmen. Diese Ausnahmen entsprechen möglicherweise nicht den Erwartungen an die Location-Blöcke. Daher  bearbeiten sie die Anfrage eventuell nicht wie erwartet.

Diese internen Weiterleitungen können aufgrund einiger Direktiven auftreten, darunter:

• index
• rewrite
• error_page
• try_files

Wenn Sie die index-Direktive verwenden, führt dies während der Anfrageverarbeitung immer zu einer internen Weiterleitung. Während das Finden von Location-Übereinstimmungen normalerweise die Ausführung des Algorithmus beendet, um den Auswahlprozess zu beschleunigen, wird die Anfrage, wenn die gefundene Location-Übereinstimmung ein Verzeichnis ist, wahrscheinlich an eine andere Location weitergeleitet, um formell verarbeitet zu werden.

Beispielsweise stimmt die folgende erste Location mit einer Anfrage-URI von /exact überein. Um die Anfrage jedoch zu verarbeiten, leitet die index-Direktive, die der Location-Block erbt, die Anfrage an einen sekundären Block weiter:

Wenn die Ausführung in diesem Szenario innerhalb des primären Blocks verbleiben muss, muss ein anderes Schema die Anfrage an das Verzeichnis verarbeiten. Eine Möglichkeit hierfür besteht darin, einen ungültigen Index für den betreffenden Block einzurichten und stattdessen Autoindex zu aktivieren:

Obwohl diese Methode in einigen Fällen funktionieren mag, ist sie in den meisten Kontexten im Großen und Ganzen nicht praktisch anwendbar. Eine exakte Verzeichnisübereinstimmung kann für Situationen nützlich sein, in denen die Anfrage umgeschrieben werden muss. Dies löst eine völlig neue Location-Suche aus.

Eine weitere Direktive, mit der der Verarbeitungsort neu bewertet werden kann, ist die try_files-Direktive. Sie weist Nginx an, gezielt zu prüfen, ob eine bestimmte Gruppe von Dateien oder Verzeichnissen existiert, wobei das letzte Suchkriterium die URI ist, an die Nginx intern weiterleiten soll.

Betrachten wir die folgende Konfiguration:

Wenn eine Anfrage für /blahblah eingeht, wird diese von der ersten Location empfangen. Wenn die Datei blahblah im Verzeichnis /var/www/main nicht gefunden wird, wird eine Folgesuche nach blahblah.html ausgelöst. Anschließend wird nach einem Unterverzeichnis namens blahblah im Verzeichnis /var/www/main gesucht. Wenn alle diese Prüfungen fehlschlagen, wird an /fallback/index.html weitergeleitet. Dies löst eine weitere Location-Suche aus, die von einem anderen Location-Block aufgegriffen wird. Anschließend wird die Datei /var/www/another/fallback/index.html verarbeitet.

Eine weitere Direktive, die zu einer Weiterleitung an einen anderen Location-Block führt, ist die rewrite-Direktive. Nginx sucht nach einer neuen passenden Location basierend auf dem Ergebnis der rewrite-Direktive, wenn der Parameter last verwendet wird. Wenn das letzte Beispiel so geändert wird, dass es nun diese rewrite-Direktive enthält, wird deutlich, dass die Anfrage an eine andere Location weitergeleitet werden kann, ohne dass die try_files-Direktive implementiert werden muss:

In diesem Beispiel wird die Anfrage für /rewrite/hello zunächst von der ersten Location bearbeitet. Nachdem sie in /hello umgeschrieben wurde, wird eine zweite Location-Suche ausgelöst. Diese wird mit der ersten Location übereinstimmen. Sie wird von der try_file-Direktive verarbeitet, wobei möglicherweise auf /fallback/index.html zurückgegriffen wird, wenn sie keine Treffer liefert.

Wenn jedoch eine Anfrage für /rewrite/fallback/hello gestellt wird, wird eine Übereinstimmung mit dem ersten Block gefunden. Daher wird das Rewrite erneut verarbeitet, liefert diesmal jedoch /fallback/hello als Ergebnis. Die Anfrage wird in einem anderen Location-Block verarbeitet.

Ähnliche Situationen treten auf, wenn Sie die return-Direktive verwenden, um die Statuscodes 301 oder 302 zu senden. Der einzige Unterschied besteht darin, dass eine neue Anfrage entsteht, was sich in einer sehr offensichtlichen Weiterleitung äußert. Ähnlich kann dies bei der rewrite-Direktive auftreten, wenn Sie die Flags permanent oder redirect anwenden.

Eine weitere Direktive, die zu ähnlichen internen Weiterleitungen wie try_again führen kann, ist die error_page-Direktive. Sie können diese verwenden, wenn Sie bei der Verarbeitung auf bestimmte Fehlercodes stoßen. Wenn eine try_files-Direktive festgelegt ist, wird die error_page-Direktive wahrscheinlich nie ausgeführt. Das liegt daran, dass diese Direktive den gesamten Lebenszyklus der Anfrage verarbeitet.

Betrachten wir das folgende Beispiel:

In diesem Fall wird jede Anfrage vom ersten Block verarbeitet, der Dateien aus /var/www/main bereitstellt. Dies gilt nicht für Anfragen, die mit /another beginnen. Wenn jedoch eine Datei nicht gefunden werden sollte, wird eine interne Weiterleitung zu /another/whoops/html initiiert. Dies führt zu einer weiteren Location-Suche. Diese wiederum leitet die Anfrage an einen sekundären Block weiter, wobei diese Datei aus /var/www/another/whoops.html bedient wird.

Wie sich zeigt, kann das Verständnis von Situationen, in denen Nginx eine neue Location-Suche auslöst, helfen, das Systemverhalten bei der Verarbeitung von Anfragen besser vorherzusagen.

Fazit

Die Arbeit von Administratoren wird ungemein einfacher, wenn sie die Methoden verstehen, mit denen Nginx Client-Anfragen verarbeitet. Dies ermöglicht es Administratoren festzustellen, an welchen Server-Block die Anfrage weitergeleitet wird. Sie können auch bestimmen, welcher Location-Block basierend auf der Anfrage-URI ausgewählt wird. Im Großen und Ganzen gibt es Administratoren auch die Möglichkeit, die von Nginx angewendeten Kontexte bei der Bearbeitung jeder Anfrage nachzuvollziehen.

Schließlich können Sie sich die anderen Tutorials auf unserem Blog ansehen, die sich mit Nginx befassen. Sie werden Ihnen helfen, besser von einem der beliebtesten Webserver der Welt zu profitieren:

• Die Welt der Webserver: Apache vs. Nginx
• So sichern Sie Nginx mit Let’s Encrypt auf Ubuntu 20.04
• Automatisieren der Verlängerung von LetsEncrypt-SSL-Zertifikaten für Nginx
• Bereitstellung von Laravel, Nginx und MySQL mit Docker Compose

Frohes Schaffen!