Detaillierte Erläuterung zur Konfiguration des Beispielcodes für den Nginx-Webserver

Überblick

Heute werden wir hauptsächlich erläutern, wie man NGINX als Webserver konfiguriert. Dabei werden die folgenden Teile einbezogen:

• Einrichten eines virtuellen Servers
• Konfigurationsspeicherort
• Verwenden von Variablen
• Einen bestimmten Statuscode zurückgeben
• Umschreiben von HTTP-Antworten

Auf einer hohen Ebene gibt es einige Dinge, die Sie verstehen müssen, wenn Sie NGINX als Webserver konfigurieren und definieren, welche URLs es verarbeitet und wie es HTTP-Anfragen für Ressourcen unter diesen URLs verarbeitet. Auf einer niedrigen Ebene definiert eine Konfiguration eine Reihe virtueller Server, die die Verarbeitung von Anforderungen für eine bestimmte Domäne oder IP-Adresse steuern.

Jeder für den HTTP-Verkehr verwendete virtuelle Server definiert spezielle Konfigurationsinstanzen, sogenannte Standorte, die die Handhabung eines bestimmten URI-Satzes steuern. Jeder Standort definiert seine eigene Zuordnung dafür, was mit Anfragen an diesen Standort geschieht. NGINX hat die volle Kontrolle über diesen Prozess. Jeder Standort kann eine Anfrage als Proxy weiterleiten oder eine Datei zurückgeben. Darüber hinaus kann die URI geändert werden, um die Anforderung an einen anderen Standort oder virtuellen Server umzuleiten. Darüber hinaus können bestimmte Fehlercodes zurückgegeben und bestimmte Seiten so konfiguriert werden, dass sie den einzelnen Fehlercodes entsprechen.

1. Richten Sie einen virtuellen Server ein

Die NGINX-Konfigurationsdatei muss mindestens eine Serverdirektive enthalten, um einen virtuellen Server zu definieren. Wenn NGINX eine Anfrage verarbeitet, wählt es zunächst einen virtuellen Server aus, der die Anfrage bedient.

Ein virtueller Server wird durch eine Serverdirektive im HTTP-Kontext definiert, zum Beispiel:

http { 
 Server { 
 # Serverkonfiguration 
 } 
}

Um mehrere virtuelle Server zu definieren, können dem HTTP-Kontext mehrere Serverdirektiven hinzugefügt werden.

Der Serverkonfigurationsblock enthält normalerweise eine Abhördirektive, die die IP-Adresse und den Port (oder den Unix-Domain-Socket und -Pfad) angibt, auf denen der Server auf Anforderungen wartet. Es werden sowohl IPv4- als auch IPv6-Adressen akzeptiert. Schließen Sie die eckigen Klammern ( ein.

Das folgende Beispiel zeigt die Konfiguration eines Servers, der auf der IP-Adresse 127.0.0.1 und dem Port 8080 lauscht:

Server { 
 hören Sie 127.0.0.1:8080; 
 # Der Rest der Serverkonfiguration 
}

Wenn der Port weggelassen wird, wird der Standardport verwendet. Wenn eine Adresse weggelassen wird, überwacht der Server ebenfalls alle Adressen. Wenn keine Listen-Direktive enthalten ist, ist der „Standard“-Port 80/TCP und der „Standard“-Port 8000/TCP, abhängig von den Superuser-Berechtigungen.

Wenn mehr als ein Server mit der angeforderten IP-Adresse und dem angeforderten Port übereinstimmt, prüft NGINX das Host-Header-Feld der Anforderung anhand der Servername-Direktive im Serverblock. Das Servername-Argument kann ein vollständiger (genauer) Name, ein Platzhalter oder ein regulärer Ausdruck sein. Ein Platzhalter ist eine Zeichenfolge, die am Anfang, am Ende oder an beiden Enden ein Sternchen (*) enthält. Das Sternchen steht für eine beliebige Zeichenfolge. NGINX verwendet für reguläre Ausdrücke die Perl-Syntax; stellen Sie ihnen eine Tilde () voran. Dieses Beispiel veranschaulicht einen exakten Namen.

Server { 
 hören Sie 80; 
 Servername example.org www.example.org; 
 ... 
}

2. Konfigurationsort

NGINX kann basierend auf der Anforderungs-URI Datenverkehr an verschiedene Proxys senden oder unterschiedliche Dateien bereitstellen. Diese Blöcke werden mithilfe von Standortdirektiven definiert, die in der Serverdirektive platziert sind.

Sie können beispielsweise drei Standortblöcke definieren, um den virtuellen Server anzuweisen, einige Anforderungen an einen Proxyserver, andere Anforderungen an einen anderen Proxyserver zu senden und den Rest durch Bereitstellung von Dateien aus dem lokalen Dateisystem zu erfüllen.

Der NGINX-Test fordert die URI basierend auf den Parametern aller Standortdirektiven an und wendet die in den übereinstimmenden Standorten definierten Direktiven an. Innerhalb jedes Standortblocks ist es im Allgemeinen (mit einigen Ausnahmen) möglich, weitere Standortanweisungen zu platzieren, um die Handhabung spezifischer Anforderungssätze weiter zu verfeinern.

Hinweis: In diesem Tutorial-Artikel bezieht sich das Wort „Standort“ auf einen einzelnen Standortkontext.

Die Standortdirektive akzeptiert zwei Arten von Argumenten: eine Präfixzeichenfolge (Pfadname) und einen regulären Ausdruck. Damit eine Anforderungs-URI mit der Präfixzeichenfolge übereinstimmt, muss sie mit der Präfixzeichenfolge beginnen.

Der folgende Beispielspeicherort mit dem Parameter pathname stimmt mit Anforderungs-URIs überein, die mit /some/path/ beginnen, z. B. /some/path/document.html. Er stimmt nicht mit /my-site/some/path überein, da /some/path nicht am Anfang dieser URI erscheint.

Standort /irgendein/Pfad/ { 
 ... 
}

Dem regulären Ausdruck ist eine Tilde (~) für die Groß-/Kleinschreibung vorangestellt, bzw. eine Tilde (~*) für die Groß-/Kleinschreibung. Das folgende Beispiel gleicht URIs ab, die irgendwo die Zeichenfolge .html oder .html enthalten.

Standort ~ \.html? { 
 ... 
}

Um den Speicherort zu finden, der am besten zu einer URI passt, vergleicht NGINX zunächst die URI mit dem Speicherort der Präfixzeichenfolge. Suchen Sie dann den Standort mit einem regulären Ausdruck.

Der Standortkontext kann Anweisungen enthalten, die definieren, wie die Anforderung aufgelöst werden soll – um statische Dateien bereitzustellen oder um die Anforderung an einen Proxyserver weiterzuleiten. Im folgenden Beispiel stellen Anforderungen, die dem ersten Standortkontext entsprechen, Dateien aus dem Verzeichnis /data/images bereit, und Anforderungen, die dem zweiten Standort entsprechen, werden an den Proxyserver weitergeleitet, der Inhalte für die Domäne www.example.com hostet.

Server { 
 Standort /Bilder/ { 
 Wurzel /Daten; 
 } 
 Standort / { 
 Proxy-Passwort http://www.example.com; 
 } 
}

Die Root-Direktive gibt den Dateisystempfad an, in dem nach bereitzustellenden statischen Dateien gesucht werden soll. Die mit dem Standort verknüpfte Anforderungs-URI wird an den Pfad angehängt, um den vollständigen Namen der bereitzustellenden statischen Datei zu erhalten. Im obigen Beispiel stellt NGINX als Antwort auf die Anfrage nach /images/logo.png die tatsächliche entsprechende Datei lokal auf dem Server bereit: /data/images/logo.png.

Die Direktive „proxy_pass“ übergibt die Anforderung unter Verwendung der konfigurierten URL an den Proxyserver. Die Antwort des Proxyservers wird dann an den Client zurückgesendet. Im obigen Beispiel werden alle Anforderungen für URIs, die nicht mit /images/ beginnen, an den Proxyserver weitergeleitet (z. B. www.example.com).

3. Verwenden von Variablen

Sie können Variablen in der Konfigurationsdatei verwenden, um NGINX dazu zu bringen, Anfragen je nach den von Ihnen definierten Umständen unterschiedlich zu verarbeiten. Variablen sind benannte Werte, die zur Laufzeit berechnet und als Argumente für Anweisungen verwendet werden. Eine Variable wird durch ein $-Zeichen (Dollar) am Anfang ihres Namens gekennzeichnet. Variablen definieren Informationen basierend auf dem Status von NGINX, z. B. Eigenschaften der gerade verarbeiteten Anfrage.

Es gibt viele vordefinierte Variablen, z. B. die zentralen HTTP-Variablen, und Sie können mit den Anweisungen „Set“, „Map“ und „Geo“ benutzerdefinierte Variablen definieren. Die meisten Variablen werden zur Laufzeit berechnet und enthalten Informationen, die für eine bestimmte Anforderung relevant sind. Beispielsweise enthält $remote_addr die Client-IP-Adresse und $uri den aktuellen URI-Wert.

4. Einen bestimmten Statuscode zurückgeben

Einige Website-URIs müssen sofort eine Antwort mit einem bestimmten Fehler- oder Umleitungscode zurückgeben, beispielsweise wenn eine Seite vorübergehend oder dauerhaft verschoben wird. Am einfachsten geht das über die Retourenanweisung. Beispielsweise wird der Statuscode „404 Nicht gefunden“ zurückgegeben:

Standort /falsche/URL { 
 Rückgabe 404; 
}

Der erste zurückgegebene Parameter ist der Antwortcode. Das optionale zweite Argument kann eine URL sein, zu der weitergeleitet werden soll (Codes 301, 302, 303 und 307), oder ein Text, der im Antworttext zurückgegeben werden soll. Zum Beispiel:

Standort /dauerhaft/verschoben/URL { 
 Rückgabewert 301 http://www.example.com/moved/here; 
}

Rückgabeanweisungen können sowohl im Standort- als auch im Serverkontext enthalten sein.

5. HTTP-Antwort neu schreiben

Manchmal müssen Sie den Inhalt einer HTTP-Antwort neu schreiben oder ändern und eine Zeichenfolge durch eine andere ersetzen. Mit der Direktive „sub_filter“ können Sie die anzuwendenden Umschreibungen definieren. Die Direktive unterstützt Variablen und Substitutionsketten, wodurch komplexere Änderungen möglich werden.

Sie können beispielsweise den absoluten Link ändern, um auf den Proxyserver zu verweisen:

Standort / { 
 Unterfilter /blog/ /blog-staging/; 
 Unterfilter_einmal aus; 
}

Ein weiteres Beispiel ändert die Methode von http:// zu http:// und ersetzt die Localhost-Adresse durch den Hostnamen aus dem Anforderungsheaderfeld. Die Direktive sub_filter_once weist NGINX an, Subfilter-Direktiven innerhalb eines Standorts nacheinander anzuwenden:

Standort / { 
 Unterfilter 'href="http://127.0.0.1:8080/'  href="http://$host/'; 
 Unterfilter 'img src="http://127.0.0.1:8080/'   img src="http://$host/'; 
 sub_filter_once ein; 
}

Beachten Sie, dass der mit dem Subfilter geänderte Teil der Antwort nicht mehr ersetzt wird, wenn eine weitere Subfilter-Übereinstimmung auftritt.

Dies ist das Ende dieses Artikels über den Beispielcode zur Konfiguration des Webservers mit Nginx. Weitere Informationen zur Konfiguration des Webservers mit Nginx finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!