Verstehen Sie wirklich, wie man Nginx als Webserver konfiguriert?

Verstehen Sie wirklich, wie man Nginx als Webserver konfiguriert?
Vor dem Lesen wird empfohlen, die Erste Einführung in Nginx zu lesen. Werfen wir anschließend einen Blick auf die Nginx-Konfiguration.
Abstrakt ausgedrückt besteht die Konfiguration von Nginx als Webserver darin, zu definieren, welche URLs verarbeitet werden sollen und wie die diesen URLs entsprechenden Anforderungen verarbeitet werden sollen. Insbesondere geht es darum, einige virtuelle Server (virtuelle Server) zu definieren, um Anforderungen mit bestimmten IP- und Domänennamen zu steuern.
Genauer gesagt steuert Nginx die Auswahl von URIS durch die Definition einer Reihe von Standorten. Jeder Standort definiert ein Verarbeitungsszenario für die ihm zugeordnete Anforderung: Zurückgeben einer Datei- oder Proxy-Anfrage oder Zurückgeben verschiedener Fehlerseiten basierend auf unterschiedlichen Fehlercodes. Darüber hinaus kann die Anfrage je nach URI auch auf andere Server oder Standorte umgeleitet werden.
Richten Sie einen virtuellen Server ein
Hör zu:
Die Nginx-Konfigurationsdatei enthält mindestens einen Serverbefehl, der zur Definition eines virtuellen Servers verwendet wird. Wenn eine Anfrage eingeht, wählt Nginx zunächst einen virtuellen Server aus, der die Anfrage bearbeitet.
Der virtuelle Server wird im Server im http-Kontext definiert:
http { server { # Serverkonfiguration
}
}
Hinweis: In http
können mehrere Server definiert werden Der Serverkonfigurationsblock verwendet den Listen-Befehl, um die lokale IP- und Portnummer (einschließlich Unix-Domänen-Socket und -Pfad) zu überwachen. Die IPv6-Adresse muss in eckigen Klammern eingeschlossen werden server { listen 127.0.0.1:8080; # IPv4-Adresse, Port 8080
# listen [2001:3CA1:10F:1A:121B:0:0:10]:80; # IPv6-Adresse, Port 80
# listen [::]:80; # Alle IPv4- und IPv6-Adressen dieser Maschine abhören, Port 80
# Der Rest der Serverkonfiguration🎜> Wenn in der obigen Konfiguration die Portnummer nicht geschrieben wird, wird standardmäßig Port 80 verwendet. Wenn die IP nicht geschrieben wird, werden alle IPs des lokalen Computers überwacht.
Servername:
Wenn die Abhör-IPs und Portnummern mehrerer Server genau gleich sind, übergibt Nginx den Host
im Anforderungsheader. Verstehen Sie wirklich, wie man Nginx als Webserver konfiguriert?

Vergleichen Sie mit dem durch server_name definierten Hostnamen, um den geeigneten virtuellen Server zur Bearbeitung der Anfrage auszuwählen:
server { listen 80;
Servername lufficc.com www.lufficc.com;
...
}
Die Parameter von server_name können sein:
Der vollständige Hostname, zum Beispiel: api.lufficc.com.
Enthält Platzhalter (einschließlich *), wie zum Beispiel: *.lufficc.com oder api.*.
Regulärer Ausdruck, beginnend mit ~.
Platzhalterzeichen dürfen nur am Anfang oder Ende stehen und nur neben einem stehen. Weder www.*.example.org noch w*.example.org sind gültig. Sie können jedoch reguläre Ausdrücke verwenden, um diese Namen abzugleichen, z. B. ~^www..+.example.org$ und ~^w.*.example.org$ . Und * kann mit mehreren Teilen übereinstimmen. Der Name *.example.org passt nicht nur zu www.example.org, sondern auch zu www.sub.example.org.
Für reguläre Ausdrücke: Die von Nginx verwendeten regulären Ausdrücke sind mit den regulären Ausdrücken der Programmiersprache Perl (PCRE) kompatibel. Um einen regulären Ausdruck zu verwenden, muss er mit ~ beginnen.
Benannte reguläre Ausdrücke können Variablen erfassen und dann Folgendes verwenden:
server { server_name ~^(www.)?(?.+)$; location / { root /sites/$domain;
}
}
Der zwischen Klammern () übereinstimmende Inhalt kann später auch von $1 referenziert werden, und $2 stellt den Inhalt in der vorletzten () dar. Daher kann der obige Inhalt auch wie folgt geschrieben werden:
server { server_name ~^(www.)?(.+)$; location / { root /sites/$2;
}
}
Ein Beispiel für einen Servernamen:
server { listen 80;
Servername api.lufficc.com *.lufficc.com;
...
}
Wenn mehrere Namen mit dem Host-Header übereinstimmen, wählt Nginx ebenfalls in der folgenden Reihenfolge aus:
Der vollständige Hostname, z. B. api.lufficc.com.
Der längste Platzhaltername, der mit * beginnt, wie zum Beispiel: *.lufficc.com.
Der längste Platzhaltername, der mit * endet, wie zum Beispiel: api.*.
Der erste passende reguläre Ausdruck. (Befolgen Sie die Reihenfolge in der Konfigurationsdatei)
Das heißt, die Priorität: api.lufficc.com > *.lufficc.com >
Wenn der Host-Header mit keinem Servernamen übereinstimmt, leitet Nginx die Anfrage an den standardmäßigen virtuellen Server weiter. Der standardmäßige virtuelle Server bezieht sich auf: den ersten Server in der Datei nginx.conf oder explizit mit default_server deklariert:
server { listen 80 default_server;
...
}
Standort konfigurieren
Übereinstimmung von URI und Standortparametern
Nach Auswahl des Servers wählt Nginx anhand der URIs den entsprechenden Speicherort aus, um zu entscheiden, ob die Anfrage weitergeleitet oder die Datei zurückgegeben werden soll.
Die Standortanweisung akzeptiert zwei Arten von Parametern:
Präfixzeichenfolge (Pfadname)
Regulärer Ausdruck
Bei Präfix-String-Parametern müssen URIs unbedingt damit beginnen. Beispielsweise stimmt der Parameter /some/path/ mit /some/path/document.html überein, aber nicht mit /my-site/some/path, da /my-site/some/path nicht mit /some beginnt /Weg/.
Standort /some/path/ {
...
}
Bei regulären Ausdrücken bedeutet der Beginn mit ~, dass die Groß-/Kleinschreibung beachtet wird, und der Beginn mit ~*, dass die Groß-/Kleinschreibung nicht beachtet wird. Beachten Sie, dass die . im Pfad als geschrieben werden sollte. Beispielsweise ein Speicherort, der mit URIs übereinstimmt, die auf .html oder .htm enden:
Standort ~ .html? {
...
}
Reguläre Ausdrücke haben eine höhere Priorität als Präfixzeichenfolgen. Wenn eine passende Präfixzeichenfolge gefunden wird, wird die Suche nach dem regulären Ausdruck weiterhin fortgesetzt. Wenn die Präfixzeichenfolge jedoch mit ^~ beginnt, wird der reguläre Ausdruck nicht mehr überprüft.
Der spezifische Such- und Abgleichsprozess ist wie folgt:
Vergleicht den URI mit allen Präfixzeichenfolgen.
Der Modifikator = gibt an, dass der URI mit der Präfixzeichenfolge identisch sein muss (nicht Start-URI, aber gleich), und wenn er gefunden wird, stoppt die Suche.
Wenn die längste gefundene Präfix-Übereinstimmungszeichenfolge mit ^~ beginnt, wird der reguläre Ausdruck nicht mehr nach einer Übereinstimmung durchsucht.
Speichert die längste passende Präfixzeichenfolge.
Testen Sie den Vergleich von URIs mit regulären Ausdrücken.
Stoppt, nachdem der erste passende reguläre Ausdruck gefunden wurde.
Wenn keine Übereinstimmung mit dem regulären Ausdruck vorliegt, wird der Speicherort verwendet, der der in 4 gespeicherten Präfixzeichenfolge entspricht.
Der Modifikator = hat die höchste Priorität. Wenn die Homepage der Website häufig besucht wird, können wir gezielt einen Ort definieren, um die Anzahl der Suchtreffer zu reduzieren (da die Suche nach einem passenden Ort, der mit = geändert wird, die Suche stoppt) und die Geschwindigkeit zu verbessern:
Standort = / {
...
}
Statische Dateien und Proxys
Der Speicherort definiert auch, wie mit übereinstimmenden Anfragen umgegangen wird: statische Dateien zurückgeben oder an einen Proxyserver übergeben. Im folgenden Beispiel gibt der erste Standort statische Dateien im Verzeichnis /data zurück und der zweite Standort leitet die Anforderung zur Verarbeitung an den Server des Domänennamens https://lufficc.com weiter:
server { location /images/ { root /data;
} location / { Proxy_pass https://lufficc.com;
}
}
Die Root-Direktive definiert das Stammverzeichnis der statischen Datei und wird mit dem URI verkettet, um den endgültigen lokalen Dateipfad zu bilden. Wenn beispielsweise /images/example.png angefordert wird, wird nach dem Spleißen die lokale Serverdatei /data/images/example.png zurückgegeben.
Die Proxy_pass-Direktive leitet die Anfrage an den Proxyserver weiter, auf den die URL verweist. Die Antwort vom Proxyserver wird dann an den Client weitergeleitet. Im obigen Beispiel werden alle Anfragen für URIs, die nicht mit /images/ beginnen, zur Verarbeitung an den Proxyserver weitergeleitet.
Wenn ich beispielsweise „proxy_pass“ auf „https://www.baidu.com/“ setze, erhält der Besuch von „http://search.lufficc.com/“ die gleiche Antwort (Seite) wie die Baidu-Homepage (interessierte Kinderschuhe können die Suche ausprobieren). von selbst) Funktion, nicht anders als Baidu):
Server{
Hör zu 80;
Servername search.lufficc.com;
Standort / {
Proxy_Pass https://www.baidu.com;
}
}
Verwenden von Variablen
Sie können Variablen verwenden, um Nginx dazu zu bringen, verschiedene Anfragen unterschiedlich zu verarbeiten. Variablen werden zur Laufzeit berechnet und als Argumente für Anweisungen verwendet. Variablen werden durch Symbole dargestellt, die mit $ beginnen. Variablen definieren Informationen basierend auf dem Status von Nginx, beispielsweise Eigenschaften der aktuell verarbeiteten Anfrage.
Es gibt viele vordefinierte Variablen, wie zum Beispiel die Kern-HTTP-Variablen, und Sie können auch benutzerdefinierte Variablen mithilfe der Set-, Map- und Geo-Anweisungen definieren. Die meisten Variablen werden zur Laufzeit berechnet und enthalten Informationen zu einer bestimmten Anfrage. Beispielsweise enthält $remote_addr die IP-Adresse des Clients und $uri den aktuellen URI-Wert.
Einige häufig verwendete Variablen sind wie folgt:
Variablennamenfunktion
$uri Der aktuelle URI in der Anfrage (ohne Anfrageparameter), der durch interne Umleitung oder mithilfe der Indexanweisung $uri geändert werden kann, enthält nicht den Hostnamen, z. B. /foo/bar.html.
$arg_name ist der Parametername in der Anfrage, also arg_name
in der Form arg_name=arg_value nach „?“ $hostname Hostname
$args-Parameterwert in Anfrage
$query_string dasselbe wie $args
$request stellt die Anfrageadresse des Kunden dar
$request_uri Diese Variable entspricht dem ursprünglichen URI, der einige Client-Anforderungsparameter enthält. Sie kann nicht geändert werden und enthält nicht den Hostnamen, wie zum Beispiel: /cnphp/test.php?arg=freemouse.
... ...
Eine einfache Anwendung ist die Umleitung von http zu https mit Pfadangabe:
Server{
... return 301 https://lufficc.com$request_uri;
...
}
Gibt einen bestimmten Statuscode zurück
Wenn einige Ressourcen auf Ihrer Website dauerhaft entfernt werden, ist die schnellste und prägnanteste Möglichkeit, den Return-Befehl zu verwenden, um direkt zurückzukehren:
Standort /wrong/url { return 404;
}
Der erste Rückgabeparameter ist der Antwortcode. Der optionale zweite Parameter kann die URL der Weiterleitung (entsprechend den Codes 301, 302, 303 und 307) oder der im Antworttext zurückgegebene Text sein. Zum Beispiel:
location /permanently/moved/url { return 301 http://www.example.com/moved/here;
}
Die Rückgabeanweisung kann in Standort- und Serverkontexte eingefügt werden:
Server{
Standort / { return 404;
}
}
Oder:
Server{
...return 404;
Standort / {
...
}
}
Fehlerbehandlung
Der Befehl error_page kann eine Fehlerseite für einen bestimmten Fehlercode konfigurieren oder auf andere Seiten umleiten. Das folgende Beispiel gibt die Seite /404.html zurück, wenn ein 404-Fehler auftritt.
error_page 404 /404.html;
Der Befehl „error_page“ definiert, wie mit Fehlern umgegangen wird, sodass er nicht direkt zurückgegeben wird, wohingegen „return“ sofort zurückkehrt. Wenn der Proxyserver oder Nginx während der Verarbeitung entsprechende Fehlercodes generiert, wird die entsprechende Fehlerseite zurückgegeben.
Wenn Nginx im folgenden Beispiel die Seite nicht finden kann, ersetzt es Code 404 durch Code 301 und leitet den Client zu http://example.com/new/path.html um. Diese Konfiguration ist beispielsweise nützlich, wenn ein Client immer noch versucht, mit der alten URI auf die Seite zuzugreifen. Der 301-Code informiert den Browser darüber, dass die Seite dauerhaft entfernt wurde und automatisch durch die neue zurückgegebene Adresse ersetzt werden muss.
Standort /old/path.html { error_page 404 =301 http:/example.com/new/path.html;
}
URIs neu schreiben
Die Rewrite-Direktive kann den angeforderten URI mehrmals ändern. Der erste Parameter des Umschreibens ist der reguläre Ausdruck, mit dem der URI übereinstimmen muss, und der zweite Parameter ist der zu ersetzende URI. Der dritte Parameter ist optional und gibt an, ob weiterhin überschrieben oder ein Umleitungscode (301 oder 302) zurückgegeben werden soll. Zum Beispiel:
location /users/ { rewrite ^/users/(.*)$ /show?user=$1 break;
}
Sie können mehrere Rewrite-Anweisungen in die Server- und Standortkontexte einfügen. Nginx führt Anweisungen nacheinander in der Reihenfolge aus, in der sie auftreten. Wenn Server ausgewählt ist, wird die Rewrite-Anweisung im Server einmal ausgeführt.
Nachdem Nginx eine Reihe von Rewrite-Anweisungen verarbeitet hat, wählt es einen Speicherort basierend auf dem neuen URI aus. Wenn der ausgewählte Speicherort noch Rewrite-Anweisungen enthält, werden diese nacheinander ausgeführt. Wenn der URI mit allen übereinstimmt, wird ein neuer Speicherort gesucht, nachdem alle definierten Rewrite-Anweisungen verarbeitet wurden.
Im folgenden Beispiel wird die Rewrite-Direktive mit der Return-Direktive verwendet:
Server {
...
^(/download/.*)/media/(.*)..*$ $1/mp3/$2.mp3 zuletzt umschreiben;
rewrite ^(/download/.*)/audio/(.*)..*$ $1/mp3/$2.ra last; return 403;
...
}
URIs wie /download/some/media/file werden in /download/some/mp3/file.mp3 geändert. Aufgrund des letzten Flags werden nachfolgende Anweisungen (die zweite Rewrite-Direktive und die Return-Direktive) übersprungen, Nginx bedient die Anfrage jedoch weiterhin mit dem geänderten URI. Ebenso wird ein URI wie /download/some/audio/file durch /download/some/mp3/file.ra ersetzt. Wenn der URI nicht mit der Rewrite-Anweisung übereinstimmt, gibt Nginx einen 403-Fehlercode an den Client zurück.
Der Unterschied zwischen last und break ist:
last: Stoppt die Ausführung von Rewrite-Anweisungen im aktuellen Server- oder Standortkontext, aber Nginx sucht weiterhin nach einem Standort, der mit dem umgeschriebenen URI übereinstimmt, und wendet alle Rewrite-Anweisungen am neuen Standort an (was bedeutet, dass sich der URI erneut ändern kann).
break: Stoppt die Verarbeitung der Rewrite-Direktive im aktuellen Kontext und bricht die Suche nach einem Speicherort ab, der dem neuen URI entspricht. Die Rewrite-Anweisung am neuen Speicherort wird nicht ausgeführt.
Anhang
Häufig verwendete reguläre Regeln
. : Entspricht jedem Zeichen
außer Newline-Zeichen ?: 0 oder 1 Mal wiederholen
+: Ein- oder mehrmals wiederholen
*: 0 Mal oder öfter wiederholen
d: Übereinstimmungsnummern
^: Entspricht dem Anfang der Zeichenfolge
$: Einführung in passende Zeichenfolgen
{n}: n-mal wiederholen
{n,}: n-mal oder öfter wiederholen
[c]: Entspricht einem einzelnen Zeichen c
[a-z]: Entspricht einem der Kleinbuchstaben a-z
Globale Variablen
$args: #Diese Variable entspricht den Parametern in der Anforderungszeile, genau wie $query_string
$content_length: Inhaltslängenfeld im Anforderungsheader.
$content_type: Content-Type-Feld im Anforderungsheader.
$document_root: Der in der Root-Direktive für die aktuelle Anfrage angegebene Wert.
$host: Host-Header-Feld anfordern, andernfalls der Servername.
$http_user_agent: Client-Agent-Informationen
$http_cookie: Client-Cookie-Informationen
$limit_rate: Diese Variable kann die Verbindungsrate begrenzen.
$request_method: Die vom Client angeforderte Aktion, normalerweise GET oder POST.
$remote_addr: Die IP-Adresse des Clients.
$remote_port: Der Port des Clients.
$remote_user: Benutzername, der vom Auth Basic Module authentifiziert wurde.
$request_filename: Der Dateipfad der aktuellen Anfrage, generiert durch die Root- oder Alias-Direktive und die URI-Anfrage.
$scheme: HTTP-Methode (z. B. http, https).
$server_protocol: Das von der Anfrage verwendete Protokoll, normalerweise HTTP/1.0 oder HTTP/1.1.
$server_addr: Serveradresse, dieser Wert kann nach Abschluss eines Systemaufrufs ermittelt werden.
$server_name: Servername.
$server_port: Die Portnummer, über die die Anfrage den Server erreicht.
$request_uri: Der ursprüngliche URI, der die Anforderungsparameter enthält, mit Ausnahme des Hostnamens, wie zum Beispiel: /foo/bar.php?arg=baz.
$uri: Der aktuelle URI ohne Anforderungsparameter. $uri enthält nicht den Hostnamen, z. B. /foo/bar.html.
$document_uri: Das Gleiche wie $uri.
Beispielanfrage: http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root：/var/www/html
$request_filename:/var/www/html/test1/test2/test.php