Einführung
Nginx ist ein leistungsstarker Webserver, der für die Last einiger der größten Websites im Internet verantwortlich ist. Es ist besonders gut im Umgang mit vielen gleichzeitigen Verbindungen und zeichnet sich durch die Bereitstellung statischer Inhalte aus.
Während viele Benutzer die Funktionen von Nginx kennen, werden neue Benutzer häufig durch einige der Konventionen verwirrt, die sie in Nginx-Konfigurationsdateien finden. In diesem Handbuch konzentrieren wir uns auf die Erörterung der Grundstruktur einer Nginx-Konfigurationsdatei sowie auf einige Richtlinien zum Entwerfen Ihrer Dateien.
Grundlegendes zu Nginx-Konfigurationskontexten
Dieses Handbuch behandelt die Grundstruktur der Hauptkonfigurationsdatei von Nginx. Der Speicherort dieser Datei hängt davon ab, wie Sie die Software auf Ihrem Computer installiert haben. Bei vielen Distributionen befindet sich die Datei unter + / etc / nginx / nginx.conf +. Wenn es dort nicht existiert, kann es sich auch um "+ / usr / local / nginx / conf / nginx.conf " oder " / usr / local / etc / nginx / nginx.conf +" handeln.
Eines der ersten Dinge, die Sie beim Betrachten der Hauptkonfigurationsdatei bemerken sollten, ist, dass sie in einer baumartigen Struktur organisiert zu sein scheint, die durch Klammern (die wie "+ {" und "} +" aussehen) definiert ist ). In Nginx werden die Bereiche, die diese Klammern definieren, als „Kontexte“ bezeichnet, da sie Konfigurationsdetails enthalten, die nach ihrem betroffenen Bereich getrennt sind. Grundsätzlich bieten diese Abteilungen eine Organisationsstruktur sowie eine Bedingungslogik, um zu entscheiden, ob die Konfigurationen darin angewendet werden sollen.
Da Kontexte ineinander geschichtet werden können, bietet Nginx eine Ebene der Direktivenvererbung. Wenn eine Direktive in mehreren verschachtelten Bereichen gültig ist, wird eine Deklaration in einem breiteren Kontext in der Regel als Standardwert an alle untergeordneten Kontexte weitergegeben. Die untergeordneten Kontexte können diese Werte nach Belieben überschreiben. Es ist erwähnenswert, dass ein Überschreiben von Array-Direktiven den vorherigen Wert ersetzt und nicht an ihn anhängt.
Direktiven können nur in den Kontexten verwendet werden, für die sie entworfen wurden. Nginx kann beim Lesen einer Konfigurationsdatei mit Anweisungen, die im falschen Kontext deklariert sind, Fehler machen. Die Nginx documentation enthält Informationen zu den Kontexten, in denen die einzelnen Anweisungen gültig sind. Wenn Sie sich nicht sicher sind, ist dies eine gute Referenz.
Im Folgenden werden die häufigsten Kontexte erläutert, auf die Sie bei der Arbeit mit Nginx wahrscheinlich stoßen.
Die Kernkontexte
Die erste Gruppe von Kontexten, die wir diskutieren werden, sind die Kernkontexte, die Nginx verwendet, um einen hierarchischen Baum zu erstellen und die Belange von diskreten Konfigurationsblöcken zu trennen. Dies sind die Kontexte, aus denen sich die Hauptstruktur einer Nginx-Konfiguration zusammensetzt.
Der Hauptkontext
Der allgemeinste Kontext ist der "Haupt" - oder "globale" Kontext. Es ist der einzige Kontext, der nicht in den typischen Kontextblöcken enthalten ist, die folgendermaßen aussehen:
# The main context is here, outside any other contexts
. . .
{
. . .
}Jede Direktive, die gänzlich außerhalb dieser Blöcke existiert, soll im „Hauptkontext“ stehen. Beachten Sie, dass einige Dateien, wenn Ihre Nginx-Konfiguration modular eingerichtet ist, Anweisungen enthalten, die außerhalb eines in Klammern gesetzten Kontexts zu existieren scheinen, die jedoch in einen solchen Kontext einbezogen werden, wenn die Konfiguration zusammengefügt wird.
Der Hauptkontext stellt die umfassendste Umgebung für die Nginx-Konfiguration dar. Es wird verwendet, um Details zu konfigurieren, die die gesamte Anwendung auf einer grundlegenden Ebene betreffen. Während sich die Anweisungen in diesem Abschnitt auf die unteren Kontexte auswirken, werden viele dieser Anweisungen nicht vererbt, da sie in niedrigeren Ebenen nicht überschrieben werden können.
Einige allgemeine Details, die im Hauptkontext konfiguriert werden, sind der Benutzer und die Gruppe, unter denen die Worker-Prozesse ausgeführt werden, die Anzahl der Worker und die Datei zum Speichern der PID des Hauptprozesses. Sie können sogar Dinge wie die Affinität zur Worker-CPU und die „Freundlichkeit“ der Worker-Prozesse definieren. Die Standardfehlerdatei für die gesamte Anwendung kann auf dieser Ebene festgelegt werden (dies kann in spezifischeren Kontexten überschrieben werden).
Der Ereigniskontext
Der Kontext "Ereignisse" ist im Kontext "Haupt" enthalten. Hiermit werden globale Optionen festgelegt, die sich darauf auswirken, wie Nginx Verbindungen auf allgemeiner Ebene verarbeitet. In der Nginx-Konfiguration kann nur ein einziger Ereigniskontext definiert werden.
Dieser Kontext sieht in der Konfigurationsdatei außerhalb aller anderen in Klammern gesetzten Kontexte folgendermaßen aus:
# main context
events {
# events context
. . .
}Nginx verwendet ein ereignisbasiertes Verbindungsverarbeitungsmodell, sodass die in diesem Kontext definierten Anweisungen festlegen, wie Worker-Prozesse mit Verbindungen umgehen sollen. Die hier aufgeführten Anweisungen dienen hauptsächlich dazu, die zu verwendende Verbindungsverarbeitungstechnik auszuwählen oder die Art und Weise zu ändern, in der diese Methoden implementiert werden.
Normalerweise wird die Verbindungsverarbeitungsmethode automatisch basierend auf der effizientesten Auswahl ausgewählt, die die Plattform zur Verfügung hat. Für Linux-Systeme ist normalerweise die Methode "+ epoll +" die beste Wahl.
Weitere Elemente, die konfiguriert werden können, sind die Anzahl der Verbindungen, die jeder Worker verarbeiten kann, ob ein Worker jeweils nur eine Verbindung nimmt oder alle ausstehenden Verbindungen nach Benachrichtigung über eine ausstehende Verbindung nimmt und ob Worker abwechselnd auf Ereignisse reagieren .
Der HTTP-Kontext
Wenn Sie Nginx als Webserver oder Reverse-Proxy konfigurieren, enthält der "http" -Kontext den größten Teil der Konfiguration. Dieser Kontext enthält alle Anweisungen und andere Kontexte, die erforderlich sind, um zu definieren, wie das Programm HTTP- oder HTTPS-Verbindungen verarbeitet.
Der http-Kontext ist ein Unterelement des Ereigniskontexts, daher sollten sie nebeneinander und nicht verschachtelt aufgelistet werden. Sie sind beide Kinder des Hauptkontexts:
# main context
events {
# events context
. . .
}
http {
# http context
. . .
}Während niedrigere Kontexte spezifischer werden, wie Anforderungen zu behandeln sind, steuern Direktiven auf dieser Ebene die Standardeinstellungen für jeden virtuellen Server, der darin definiert ist. Abhängig davon, wie die Vererbung funktionieren soll, können in diesem und im Folgenden eine Vielzahl von Anweisungen konfiguriert werden.
Einige der Anweisungen, auf die Sie wahrscheinlich stoßen, steuern die Standardspeicherorte für Zugriffs- und Fehlerprotokolle ("+ access_log " und " error_log "). Konfigurieren Sie asynchrone E / A für Dateioperationen (" aio ", " sendfile ", und ` directio `), und konfigurieren Sie den Serverstatus, wenn Fehler auftreten (` error_page `). Andere Direktiven konfigurieren die Komprimierung (` gzip ` und ` gzip_disable `), optimieren die TCP-Keep-Alive-Einstellungen (` keepalive_disable `, ` keepalive_requests ` und ` keepalive_timeout `) und legen die Regeln fest, denen Nginx folgt Versuche Pakete und Systemaufrufe zu optimieren (` sendfile `, ` tcp_nodelay ` und ` tcp_nopush `). Zusätzliche Direktiven konfigurieren eine Dokumentstamm- und -indexdatei auf Anwendungsebene (" root " und " index ") und richten die verschiedenen Hash-Tabellen ein, die zum Speichern verschiedener Datentypen verwendet werden (" * _ hash_bucket_size " und " * _ hash_max_size +") Für + Servernamen + , + Typen + und + Variablen + `).
Der Server-Kontext
Der "Server" -Kontext wird innerhalb des "http" -Kontexts deklariert. Dies ist unser erstes Beispiel für verschachtelte, in Klammern gesetzte Kontexte. Es ist auch der erste Kontext, der mehrere Deklarationen zulässt.
Das allgemeine Format für den Serverkontext sieht möglicherweise so aus. Denken Sie daran, dass sich diese im http-Kontext befinden:
# main context
http {
# http context
server {
# first server context
}
server {
# second server context
}
}Der Grund für das Zulassen mehrerer Deklarationen des Serverkontexts besteht darin, dass jede Instanz einen bestimmten virtuellen Server für die Verarbeitung von Clientanforderungen definiert. Sie können über beliebig viele Serverblöcke verfügen, von denen jeder eine bestimmte Teilmenge von Verbindungen verarbeiten kann.
Aufgrund der Möglichkeit und Wahrscheinlichkeit mehrerer Serverblöcke ist dieser Kontexttyp auch der erste, bei dem Nginx einen Auswahlalgorithmus verwenden muss, um Entscheidungen zu treffen. Jede Client-Anfrage wird entsprechend der Konfiguration behandelt, die in einem einzelnen Serverkontext definiert ist. Daher muss Nginx anhand der Details der Anfrage entscheiden, welcher Serverkontext am besten geeignet ist. Die Anweisungen, die entscheiden, ob ein Serverblock zur Beantwortung einer Anfrage verwendet wird, sind:
-
* listen *: Die IP-Adresse / Port-Kombination, auf die dieser Serverblock reagieren soll. Wenn ein Client eine Anfrage stellt, die diesen Werten entspricht, wird dieser Block möglicherweise ausgewählt, um die Verbindung zu handhaben.
-
* Servername *: Diese Anweisung ist die andere Komponente, mit der ein Serverblock zur Verarbeitung ausgewählt wird. Wenn mehrere Serverblöcke mit Listen-Direktiven derselben Spezifität vorhanden sind, die die Anforderung verarbeiten können, analysiert Nginx den "Host" -Header der Anforderung und vergleicht ihn mit dieser Direktive.
Die Anweisungen in diesem Kontext können viele der Anweisungen überschreiben, die im http-Kontext definiert sind, einschließlich Protokollierung, Dokumentstamm, Komprimierung usw. Zusätzlich zu den Anweisungen, die aus dem http-Kontext stammen, können wir Dateien so konfigurieren, dass sie versuchen, auf Anforderungen zu antworten (+ try_files +), Weiterleitungen und Umschreibungen durchzuführen (+ return + und + rewrite +) und beliebige Werte festlegen Variablen (+ set +).
Der Standortkontext
Der nächste Kontext, mit dem Sie sich regelmäßig befassen, ist der Standortkontext. Standortkontexte haben viele relationale Eigenschaften mit Serverkontexten gemeinsam. Beispielsweise können mehrere Standortkontexte definiert werden, jeder Standort wird verwendet, um einen bestimmten Typ von Clientanforderung zu verarbeiten, und jeder Standort wird ausgewählt, indem die Standortdefinition mit der Clientanforderung über einen Auswahlalgorithmus abgeglichen wird.
Während die Anweisungen, die bestimmen, ob ein Serverblock ausgewählt werden soll, im Serverkontext definiert sind, befindet sich die Komponente, die über die Fähigkeit eines Standorts entscheidet, eine Anforderung zu verarbeiten, in der Standortdefinition (der Zeile, die den Standortblock öffnet).
Die allgemeine Syntax sieht folgendermaßen aus:
location {
. . .
}Standortblöcke befinden sich in Serverkontexten und können im Gegensatz zu Serverblöcken ineinander verschachtelt werden. Dies kann nützlich sein, um einen allgemeineren Standortkontext zu erstellen, um eine bestimmte Teilmenge des Datenverkehrs abzufangen, und ihn dann basierend auf genaueren Kriterien mit zusätzlichen Kontexten weiterzuverarbeiten:
# main context
server {
# server context
location {
# first location context
}
location {
# second location context
location {
# first nested location
}
location {
# second nested location
}
}
}Während Serverkontexte auf der Grundlage der angeforderten IP-Adresse / Port-Kombination und des Hostnamens im Host-Header ausgewählt werden, unterteilen Standortblöcke die Anforderungsbearbeitung innerhalb eines Serverblocks weiter, indem sie sich die Anforderungs-URI ansehen. Der Anforderungs-URI ist der Teil der Anforderung, der nach dem Domänennamen oder der Kombination aus IP-Adresse und Anschluss erfolgt.
Wenn ein Client "+ http: // www.example.com / blog " an Port 80 anfordert, werden " http ", " www.example.com " und "Port 80" verwendet, um zu bestimmen, welcher Server verwendet wird Block zur Auswahl. Nachdem ein Server ausgewählt wurde, wird der Teil " / blog +" (der Anforderungs-URI) anhand der definierten Speicherorte ausgewertet, um zu bestimmen, welcher weitere Kontext zur Beantwortung der Anforderung verwendet werden soll.
Viele der Anweisungen, die Sie wahrscheinlich in einem Standortkontext sehen, sind auch auf den übergeordneten Ebenen verfügbar. Neue Direktiven auf dieser Ebene ermöglichen es Ihnen, Speicherorte außerhalb des Dokumentstamms zu erreichen (+ alias +), den Speicherort als nur intern zugänglich (+ intern +) und als Proxy für andere Server oder Speicherorte (mit http, fastcgi, scgi) zu kennzeichnen und uwsgi proxying).
Andere Kontexte
Während die obigen Beispiele die wesentlichen Kontexte darstellen, denen Sie mit Nginx begegnen, existieren auch andere Kontexte. Die folgenden Kontexte wurden getrennt, da sie von optionaleren Modulen abhängen, nur unter bestimmten Umständen verwendet werden oder für Funktionen verwendet werden, die die meisten Benutzer nicht verwenden werden.
Wir werden jedoch nicht jeden der verfügbaren Kontexte diskutieren. Die folgenden Kontexte werden in keiner Tiefe erörtert:
-
*
+ split_clients +*: Dieser Kontext ist so konfiguriert, dass die Clients, die der Server empfängt, in Kategorien unterteilt werden, indem sie anhand eines Prozentsatzes mit Variablen gekennzeichnet werden. Diese können dann verwendet werden, um A / B-Tests durchzuführen, indem verschiedenen Hosts unterschiedliche Inhalte bereitgestellt werden. -
*
+ perl / perl_set +*: In diesem Kontext werden Perl-Handler für den Speicherort konfiguriert, an dem sie angezeigt werden. Dies wird nur für die Verarbeitung mit Perl verwendet. -
*
+ map +*: In diesem Kontext wird der Wert einer Variablen in Abhängigkeit vom Wert einer anderen Variablen festgelegt. Es bietet eine Zuordnung der Werte einer Variablen, um zu bestimmen, auf was die zweite Variable eingestellt werden soll. -
*
+ geo +*: Wie der obige Kontext wird dieser Kontext verwendet, um ein Mapping anzugeben. Diese Zuordnung wird jedoch speziell zum Kategorisieren von Client-IP-Adressen verwendet. Hiermit wird der Wert einer Variablen in Abhängigkeit von der IP-Adresse der Verbindung festgelegt. -
*
+ types +*: Dieser Kontext wird wieder für das Mapping verwendet. In diesem Kontext werden MIME-Typen den Dateierweiterungen zugeordnet, die ihnen zugeordnet werden sollen. Dies wird normalerweise mit Nginx über eine Datei bereitgestellt, die in der Hauptkonfigurationsdatei+ nginx.conf +enthalten ist. -
*
+ charset_map +*: Dies ist ein weiteres Beispiel für einen Mapping-Kontext. Dieser Kontext wird zum Zuordnen einer Konvertierungstabelle von einem Zeichensatz zu einem anderen verwendet. Im Context-Header werden beide Sets aufgelistet und im Body findet das Mapping statt.
Die folgenden Zusammenhänge sind nicht so häufig wie die, die wir bisher besprochen haben, aber dennoch sehr nützlich zu wissen.
Der vorgelagerte Kontext
Der Upstream-Kontext wird zum Definieren und Konfigurieren von Upstream-Servern verwendet. Grundsätzlich definiert dieser Kontext einen benannten Pool von Servern, zu denen Nginx dann Proxy-Anforderungen senden kann. Dieser Kontext wird wahrscheinlich verwendet, wenn Sie Proxys verschiedener Typen konfigurieren.
Der vorgelagerte Kontext sollte innerhalb des http-Kontexts platziert werden, außerhalb bestimmter Serverkontexte. Die allgemeine Form sieht ungefähr so aus:
# main context
http {
# http context
upstream {
# upstream context
server ;
server ;
. . .
}
server {
# server context
}
}Der Upstream-Kontext kann dann innerhalb von Server- oder Standortblöcken nach Namen referenziert werden, um Anforderungen eines bestimmten Typs an den Pool der definierten Server weiterzuleiten. Der Upstream verwendet dann einen Algorithmus (standardmäßig Round-Robin), um zu bestimmen, an welchen bestimmten Server die Anforderung weitergeleitet werden soll. Dieser Kontext gibt unserem Nginx die Möglichkeit, beim Proxying von Anfragen einen Lastausgleich vorzunehmen.
Der Mail-Kontext
Obwohl Nginx am häufigsten als Web- oder Reverse-Proxy-Server verwendet wird, kann es auch als leistungsstarker Mail-Proxy-Server fungieren. Der Kontext, der für Anweisungen dieses Typs verwendet wird, wird entsprechend als "Mail" bezeichnet. Der E-Mail-Kontext wird innerhalb des Hauptkontexts oder des globalen Kontexts (außerhalb des http-Kontexts) definiert.
Die Hauptfunktion des Mail-Kontexts besteht darin, einen Bereich zum Konfigurieren einer Mail-Proxy-Lösung auf dem Server bereitzustellen. Nginx kann Authentifizierungsanforderungen an einen externen Authentifizierungsserver umleiten. Es kann dann Zugriff auf POP3- und IMAP-Mailserver zur Bereitstellung der eigentlichen Mail-Daten gewähren. Der E-Mail-Kontext kann auch so konfiguriert werden, dass bei Bedarf eine Verbindung zu einem SMTP-Relayhost hergestellt wird.
Im Allgemeinen sieht ein E-Mail-Kontext folgendermaßen aus:
# main context
events {
# events context
}
mail {
# mail context
}Der If-Kontext
Der "if" -Kontext kann erstellt werden, um die bedingte Verarbeitung der darin definierten Anweisungen zu ermöglichen. Wie eine if-Anweisung in der konventionellen Programmierung führt die if-Direktive in Nginx die enthaltenen Anweisungen aus, wenn ein gegebener Test "true" zurückgibt.
Der if-Kontext in Nginx wird vom Rewrite-Modul bereitgestellt, und dies ist die primäre beabsichtigte Verwendung dieses Kontexts. Da Nginx die Bedingungen einer Anforderung mit vielen anderen zweckgebundenen Anweisungen testet, sollte dies für die meisten Formen der bedingten Ausführung * nicht * verwendet werden. Dies ist ein so wichtiger Hinweis, dass die Nginx-Community eine Seite namens if is evil erstellt hat.
Das Problem ist im Grunde, dass die Nginx-Verarbeitungsreihenfolge sehr oft zu unerwarteten Ergebnissen führen kann, die die Bedeutung eines if-Blocks zu untergraben scheinen. Die einzigen Anweisungen, deren Verwendung in diesen Kontexten als zuverlässig sicher angesehen wird, sind die Direktiven "+ return " und " rewrite " (für die dieser Kontext erstellt wurde). Eine andere Sache, die bei der Verwendung eines if-Kontexts beachtet werden muss, ist, dass eine Direktive ` try_files +` im selben Kontext unbrauchbar wird.
Am häufigsten wird ein if verwendet, um zu bestimmen, ob ein Umschreiben oder Zurückschreiben erforderlich ist. Diese befinden sich am häufigsten in Positionsblöcken, sodass das übliche Formular ungefähr so aussieht:
# main context
http {
# http context
server {
# server context
location {
# location context
if () {
# if context
}
}
}
}Der Limit_except-Kontext
Der Kontext "+ limit_except " wird verwendet, um die Verwendung bestimmter HTTP-Methoden in einem Standortkontext einzuschränken. Wenn zum Beispiel nur bestimmte Clients Zugriff auf POST-Inhalte haben sollen, aber jeder die Möglichkeit haben soll, Inhalte zu lesen, können Sie einen " limit_except +" - Block verwenden, um diese Anforderung zu definieren.
Das obige Beispiel würde ungefähr so aussehen:
. . .
# server or location context
location /restricted-write {
# location context
limit_except GET HEAD {
# limit_except context
allow 192.168.1.1/24;
deny all;
}
}Dies wendet die Anweisungen innerhalb des Kontexts an (um den Zugriff einzuschränken), wenn HTTP-Methoden * mit Ausnahme * der im Kontext-Header aufgelisteten Methoden auftreten. Das Ergebnis des obigen Beispiels ist, dass jeder Client die Verben GET und HEAD verwenden kann, aber nur Clients, die aus dem Subnetz + 192.168.1.1 / 24 + stammen, dürfen andere Methoden verwenden.
Allgemeine Regeln, die in Bezug auf Kontexte befolgt werden müssen
Da Sie nun eine Vorstellung von den allgemeinen Kontexten haben, auf die Sie wahrscheinlich stoßen, wenn Sie Nginx-Konfigurationen untersuchen, können wir einige bewährte Methoden für den Umgang mit Nginx-Kontexten erläutern.
Wenden Sie Anweisungen im höchsten verfügbaren Kontext an
Viele Richtlinien sind in mehreren Zusammenhängen gültig. Beispielsweise gibt es einige Direktiven, die in den Kontext http, server oder location gestellt werden können. Dies gibt uns Flexibilität bei der Festlegung dieser Richtlinien.
In der Regel ist es jedoch am besten, Richtlinien im höchsten Kontext zu deklarieren, auf den sie anwendbar sind, und sie gegebenenfalls in niedrigeren Kontexten außer Kraft zu setzen. Dies ist aufgrund des von Nginx implementierten Vererbungsmodells möglich. Es gibt viele Gründe, diese Strategie anzuwenden.
Erstens können Sie durch Deklarieren auf hoher Ebene unnötige Wiederholungen zwischen Geschwisterkontexten vermeiden. Im folgenden Beispiel deklariert beispielsweise jeder Speicherort denselben Dokumentstamm:
http {
server {
location / {
root /var/www/html;
. . .
}
location /another {
root /var/www/html;
. . .
}
}
}Sie können das Stammverzeichnis in den Serverblock oder sogar in den http-Block verschieben, wie folgt:
http {
root /var/www/html;
server {
location / {
. . .
}
location /another {
. . .
}
}
}Meistens ist die Serverebene am besten geeignet, aber das Deklarieren auf der höheren Ebene hat seine Vorteile. Auf diese Weise können Sie nicht nur die Direktive an weniger Stellen festlegen, sondern auch den Standardwert auf alle untergeordneten Elemente herunterkaskadieren, um Situationen zu vermeiden, in denen ein Fehler auftritt, indem Sie eine Direktive auf einer niedrigeren Ebene vergessen. Dies kann bei langen Konfigurationen ein großes Problem sein. Wenn Sie auf einer höheren Ebene deklarieren, erhalten Sie eine vernünftige Standardeinstellung.
Verwenden Sie mehrere Geschwisterkontexte anstelle der If-Logik für die Verarbeitung
Wenn Sie Anforderungen unterschiedlich behandeln möchten, abhängig von einigen Informationen, die in der Clientanforderung enthalten sind, wechseln Benutzer häufig in den "if" -Kontext, um die Verarbeitung zu konditionieren. Es gibt einige Probleme, auf die wir kurz eingegangen sind.
Die erste ist, dass die If-Anweisung häufig Ergebnisse zurückgibt, die nicht den Erwartungen des Administrators entsprechen. Obwohl die Verarbeitung bei gleicher Eingabe immer zum gleichen Ergebnis führt, kann die Art und Weise, wie Nginx die Umgebung interpretiert, erheblich von derjenigen abweichen, die ohne umfangreiche Tests angenommen werden kann.
Der zweite Grund dafür ist, dass es bereits optimierte, zweckgerichtete Richtlinien gibt, die für viele dieser Zwecke verwendet werden. Nginx verwendet bereits einen gut dokumentierten Auswahlalgorithmus für die Auswahl von Server- und Standortblöcken. Wenn es also möglich ist, ist es am besten, die verschiedenen Konfigurationen in ihre eigenen Blöcke zu verschieben, damit dieser Algorithmus die Auswahlprozesslogik handhaben kann.
Anstatt sich beispielsweise auf das erneute Schreiben zu verlassen, um eine vom Benutzer bereitgestellte Anforderung in das Format zu bringen, mit dem Sie arbeiten möchten, sollten Sie versuchen, zwei Blöcke für die Anforderung einzurichten, von denen einer die gewünschte Methode darstellt und der andere abfängt unordentliche Anforderungen und leitet sie an den richtigen Block weiter (und schreibt sie möglicherweise neu).
Das Ergebnis ist in der Regel besser lesbar und hat den zusätzlichen Vorteil, dass es leistungsfähiger ist. Richtige Anforderungen werden nicht weiter verarbeitet, und in vielen Fällen können falsche Anforderungen mit einer Umleitung und nicht mit einem Überschreiben auskommen, das mit geringerem Aufwand ausgeführt werden sollte.
Fazit
Zu diesem Zeitpunkt sollten Sie einen guten Überblick über die gängigsten Kontexte von Nginx und die Direktive haben, mit der die Blöcke erstellt werden, die sie definieren.
Überprüfen Sie immer Nginxs Dokumentation, um Informationen darüber zu erhalten, in welchen Kontexten eine Direktive platziert werden kann, und um den effektivsten Standort zu ermitteln. Wenn Sie beim Erstellen Ihrer Konfigurationen vorsichtig vorgehen, wird nicht nur die Wartbarkeit erhöht, sondern häufig auch die Leistung.