Statische Dateien Nginx ist für seine hohe Leistung bekannt und wird häufig als Front-End-Reverse-Proxy-Server verwendet. Gleichzeitig ist nginx auch ein leistungsstarker statischer Dateiserver. Normalerweise wird nginx verwendet, um die statischen Dateien der Anwendung zu verarbeiten. Es gibt zwei Anweisungen zum Konfigurieren statischer Nginx-Dateien: eine Root und einen Alias. Bei diesen beiden Anweisungen ist es oft verwirrend, ob nach dem Pfad ein Schrägstrich hinzugefügt werden soll. Dieser Artikel fasst eine gängigere Konfigurationsmethode zusammen, indem verschiedene Übereinstimmungsregeln ausprobiert werden. Grundkonfiguration Ähnlich wie beim Experiment zur Standort-URL-Konfiguration im Artikel „Nginx-Standort-URL“ wird in diesem Artikel auch Nginx in der virtuellen Vagrant-Maschine verwendet. Die Grundkonfiguration ist wie folgt: /etc/nginx/sites-enabled/pro.conf Server { hören Sie 80 Standardserver; Servername localhost; Zugriffsprotokoll /var/log/nginx/pro/access.log; Fehlerprotokoll /var/log/nginx/pro/error.log; Fehlerseite 404 /404.html; root /vagrant/pro; Index Index.html Index.htm; } Das Projektverzeichnis sieht wie folgt aus: pro Baum . ├── 403.html ├── 404.html ├── index.html ├── statisch │ ├── Flasche │ │ └── m.png │ └── stc.jpg └── hochladen └── nach oben.png 3 Verzeichnisse, 6 Dateien Es gibt zwei statische Ordner, einer ist statisch und der andere ist zum Hochladen. Root kennenlernen root gibt das Stammverzeichnis des Projekts an und gilt für Server und Standort. Sie können mehrere Standorte angeben. Wenn kein Standort angegeben ist, wird der Server- oder HTTP-Standort verwendet, um den Standort zu übernehmen. Besuchen Sie upload/2022/web/stc.jpg und Sie werden sehen, dass das Bild zurückgegeben wurde. Wir haben den Speicherort noch nicht konfiguriert. Warum können wir die Datei also nicht richtig finden? Wenn Sie die Root- oder Alias-Direktive lernen, ist es am besten, der Dateierweiterung ein Zeichen hinzuzufügen, damit die Datei nicht auf der Festplatte vorhanden ist. Anschließend können Sie anhand des error.log von nginx sehen, wie nginx die Datei findet. Besuchen Sie upload/2022/web/stc.jpgx und überprüfen Sie dann die Datei /var/log/nginx/pro/error.log. Sie können die folgenden Fehlerinformationen sehen:
Das heißt, die Datei /vagrant/pro/static/stc.jpgx existiert nicht. Tatsächlich haben wir diese Datei nicht. Wenn der Dateiname korrekt ist, kann darauf zugegriffen werden. Der Grund dafür ist, dass auf dem Server root /vagrant/pro angegeben ist. Nginx sucht in diesem Verzeichnis nach der Datei und die Adresse in der URL ist genau dieselbe wie der Pfad der Datei. http://192.168.33.10 /static/stc.jpg /vagrant/pro /static/stc.jpg Daraus können wir schließen, dass die Adresse der Root-Direktive in Nginx tatsächlich den Host in der übereinstimmenden URL ersetzt. Root-Direktive Um die obige Vermutung zu überprüfen, müssen noch einige weitere Versuchsorte angegeben werden. Fügen Sie wie folgt eine Standortkonfiguration hinzu: Standort ^~ /static { root /vagrant/pro/static; } Besuchen Sie upload/2022/web/stc.jpg erneut und stellen Sie fest, dass das Bild nicht angezeigt werden kann. Überprüfen Sie error.log und das Ergebnis ist wie folgt:
nginx erkennt die Adresse als /vargrant/pro/static/static/stc.jpg mit einem zusätzlichen static. Unter Anwendung der obigen Regeln lautet die Kombination 192.168.33.10 == /vagrant/pro/static und die URL lautet /static/stc.jpg. Der Ersatz kann /vagrant/pro/static + /static/stc.jpg erhalten. Dasselbe wie Fehler. Die Lösung besteht darin, die statische Aufladung im Stammverzeichnis zu entfernen, und Sie können sofort auf das Bild zugreifen. Wenn ja, was ist das Ergebnis, wenn wir den statischen Ordner als „stc“ benennen? Standort ^~ /static { root /vagrant/pro; } Greifen Sie auf upload/2022/web/stc.jpg zu und erhalten Sie den Fehler:
Berechnen Sie den Pfad /vagrant/pro + /static/stc.jpg. Die Datei /vagrant/pro/static/stc.jpg kann nicht gefunden werden. Dies entspricht den oben genannten Regeln. Versuchen Sie, den Speicherort zu ändern: Standort ^~ /stc { root /vagrant/pro; } Da sich die URL geändert hat, finden Sie das Bild unter upload/2022/web/stc.jpg. Ändern Sie nun den stc-Ordner zurück in static. Wurzel mit Schrägstrich Viele fragen sich, ob der Schrägstrich / am Ende des Pfades hinzugefügt werden sollte? Der Schrägstrich nach „static“ im Standort bezieht sich auf die übereinstimmende URL, daher werde ich nicht ins Detail gehen. Der Schrägstrich / im Pfad der Wurzel kann experimentell ermittelt werden. Konfigurieren Sie den Standort wie folgt: Standort ^~ /static/ { Wurzel /vagrant/pro/; } Greifen Sie auf upload/2022/web/stc.jpg zu. Alles ist normal. Greifen Sie auf upload/2022/web/stc.jpg zu. Der Fehler besteht darin, dass die Datei „/vagrant/pro/static/stc.jpgs“ nicht gefunden werden kann. Wenn Sie der Regel folgen, Host durch Root zu ersetzen, ist der Ersetzungsprozess: /vagrant/pro/ + /static/stc.jpg == /vagrant/pro//static/stc.jpg. Auf *nix-Systemen sind mehrere Schrägstriche und ein einzelner Schrägstrich gleichwertig, d. h. /vagrant/pro//static/stc.jpg ist dasselbe wie /vagrant/pro/static/stc.jpg. Auf diese Weise ist der Effekt derselbe, unabhängig davon, ob nach dem Stammpfad ein Schrägstrich steht oder nicht. In diesem Fall wird bestimmt jemand an diese Konfiguration denken: Standort ^~ static/ { root /vagrant/pro; } Wenn der obige Algorithmus vor der Installation verwendet wird, sollte es /vagrant/pro + static/stc.jpg sein, und die Summe sollte /vagrant/prostatic/stc.jpg sein. Es sollte falsch sein, aber tatsächlich kann auf das Bild zugegriffen werden. Etwas Seltsames? Standort ^~ static/ { umschreiben ^ http://google.com; # root /vagrant/pro; } Sie können das Bild immer noch abrufen, indem Sie upload/2022/web/stc.jpg besuchen. Es gibt keinen Sprung zu Google, was bedeutet, dass es keine Übereinstimmung gibt ^~ static/. Tatsächlich ist das Prinzip ganz einfach. Erinnern Sie sich an unser erstes Experiment. Als wir den Standort nicht konfiguriert hatten, konnten wir das Bild trotzdem zurückgeben. Das stimmt. Obwohl ^~ static/ nicht übereinstimmt, definiert der äußere Server die Wurzel als /vagrant/pro, sodass die Suche nach dem Bild normal zurückgegeben wird. Kommentieren Sie dann die äußere Wurzel aus und greifen Sie erneut darauf zu. An dieser Stelle erhalten Sie einen 404-Fehler. Überprüfen Sie den Fehler wie folgt:
/usr/share/nginx/html/static/stc.jpg, was bedeutet, dass nginx standardmäßig ein Stammverzeichnis hat: /usr/share/nginx/html, auch wenn das Stammverzeichnis nicht angegeben ist. Natürlich hat diese Konfiguration nichts mit ^~ static/ zu tun. Wenn ~ static/stc.jpgs? gefunden wird, ist das Ergebnis korrekt. Daher kann das Bild beim Zugriff nicht korrekt analysiert werden. Daher gibt es keine Situation wie /vagrant/pro + static/stc.jpg. Der Schlüssel zum Verständnis besteht hier darin, Host durch Root zu ersetzen und die übereinstimmende URL hinzuzufügen. Die übereinstimmende URL enthält natürlich den führenden Schrägstrich, während dies beim übereinstimmenden Teil der URL nicht der Fall ist.
Es ist sehr wichtig, dies zu beherrschen, da es in direktem Zusammenhang mit der späteren Beziehung zwischen dem Alias-Befehl und dem Schrägstrich steht. Für die Root-Direktive können wir zusammenfassen.
Die Alias-Direktive Für Root ist der Vorgang sehr einfach. Ersetzen Sie einfach die Root-Adresse durch den Host, also den Festplattenpfad (die tatsächliche Adresse) der Datei. Beispielsweise wird dabei nicht die übereinstimmende URL-Adresse ersetzt, sondern der übereinstimmende Teil der URL. Es kann mehrere Alias-Direktiven geben. Standort ^~ /upload { Alias /vagrant/pro; } Beim Zugriff auf upload/2022/web/up.png wird kein Bild angezeigt. Überprüfen Sie den Fehler und Sie erhalten:
Es ist ersichtlich, dass das Aliasmuster nicht /vagrant/pro + /upload/up.png, sondern /vagrant/pro + /up.png ist. Das Wort Alias wird in der Computertechnik sehr häufig verwendet. Seine wörtliche Bedeutung ist „Alias“. Wie der Name schon sagt, bedeutet es, den Namen zu ändern. Die eigentliche Ersetzungsregel besteht darin, die passende URL-Adresse durch den Pfad im Alias zu ersetzen. Der Ersetzungsprozess des obigen Beispiels kann beispielsweise wie folgt simuliert werden:
Um den Zugriff auf das Bild zu ändern, ändern Sie den Speicherort wie folgt: Standort ^~ /upload { Alias /vagrant/pro/upload; } Derzeit können Sie das richtige Bild erhalten, indem Sie upload/2022/web/up.png besuchen. Der obige Berechnungsprozess ist wie folgt:
Anhand der Ergebnisse können wir erkennen, dass der Dateipfad korrekt ermittelt wurde. Wird die Aliasanweisung path mit einem Schrägstrich ergänzt, ergibt sich als berechneter Dateipfad: /hochladen == /vagrant/pro/hochladen /vagrant/pro/upload/ + /up.png Mehrere Schrägstriche sind zulässig. Entspricht dem Fall mit einem einzelnen Schrägstrich. Ändern Sie den Standort wie folgt: Standort ^~ /upload/ { Alias /vagrant/pro/upload; } Die passende URL wird zu /upload/ + up.jpg, und das Ergebnis der Ersetzung ist /vagrant/pro/upload + up.png. Der Pfad /vagrant/pro/uploadup.png ist jedoch ungültig. Der Ersetzungsfehler ist auch aus dem Fehler ersichtlich:
Die Lösung ist auch sehr einfach: Ändern Sie einfach /vagrant/pro/upload in /vagrant/pro/upload/. Es ist ersichtlich, dass der Schrägstrich am Ende des Alias nicht wie die Root-Direktive entbehrlich ist. Ob er benötigt wird, hängt vom URL-Übereinstimmungsmuster des Standorts ab. Im vorherigen Root-Modus wurde der Fall eines Schrägstrichs ohne Root (~ static/stc.jpgs?) berücksichtigt. Im Alias-Fall wäre es schwierig, Fehler abzufangen. Wenn der Standort wie folgt konfiguriert ist: Standort ^~ upload/ { Alias /vagrant/pro/upload/; } Der Ersatzdateipfad sollte /vagrant/pro/upload/up.png sein, aber bei tatsächlichen Tests führt eine solche Konfiguration des Alias immer zu einer 301-Umleitung. Wenn die automatische Indexierung im Aliasverzeichnis nicht aktiviert ist, wird ein 403-Fehler ausgegeben. Die konkrete Situation ist noch nicht bekannt und ich weiß nicht, ob es sich um einen Fehler in Nginx handelt. Um diese Situation zu vermeiden, versuchen Sie bei der Verwendung eines Alias, den Speicherort nicht als „^~ upload/“-Modus zu konfigurieren und geben Sie die URL nicht vom Stammverzeichnis aus an, da sie sonst fehl am Platz wirkt. Ein großer Vorteil der Verwendung von „alise“ als Alias gegenüber „root“ besteht darin, dass der Pfad in der URL nicht unbedingt mit dem Dateipfad übereinstimmen muss, da „alise“ nicht den Host ersetzt, sondern den passenden Teil des Hosts. Ändern Sie die Konfiguration wie folgt: Standort ^~ /upload/ { Alias /vagrant/pro/static/; } Beim Zugriff auf upload/2022/web/stc.jpg oder upload/2022/web/m.png können die Dateien im statischen Verzeichnis korrekt aufgerufen werden, auch wenn die URL „upload“ lautet. Die Ersetzungsregel ist ebenfalls einfach: /upload/ == /vagrant/pro/static/ erhält /vagrant/pro/static/ + stc.jpg oder /vagrant/pro/static/ + flask/m.png. Zusammenfassen In der statischen Dateikonfiguration von nginx können sowohl Root- als auch Alias-Direktiven implementiert werden. Um Verwirrung zu vermeiden, sollten Sie keine URL-Muster ohne Stammpfad schreiben, d. h. nicht mit static/ beginnen. Der Schrägstrich des Stammpfads muss beibehalten werden. Es wäre seltsam, keinen Stammpfad zu haben. Der Unterschied zwischen Root und Alias liegt im Ersetzungsteil. Im Root-Modus ersetzt der von Root konfigurierte Pfad den Host in der übereinstimmenden URL. Alias ersetzt den passenden Teil der URL durch den von ihm angegebenen Pfad. Der Schrägstrich im Befehl hat keine Auswirkung auf den Root-Befehl und kann beispielsweise gemäß den Ersetzungsregeln abgeglichen werden. Root-Direktive Standort /dir/ root root_pfad -> http://host/dir/file.txt -> root_pfad/dir/file.txt Die Alias-Direktive Standort /Verzeichnis Alias Aliaspfad -> http://Host /Verzeichnis /Datei.txt -> Aliaspfad/Datei.txt Standort /dir/ Alias Aliaspfad/ -> http://Host /Verzeichnis/ Datei.txt -> Aliaspfad/Datei.txt Nachdem Sie Root und Alias verstanden haben, ist es normalerweise am besten, das Root eines Projekts zu konfigurieren und Aliase für andere Ordner zu verwenden. Schließlich sind Aliase flexibler. Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird. Das könnte Sie auch interessieren:
|
<<: Installieren Sie MySQL 5.7.18 mit dem RPM-Paket unter CentOS 7
>>: 5 Dinge, die beim Schreiben von React-Komponenten mit Hooks zu beachten sind
<br />Verwandte Artikel: innerHTML HTML DOM ...
Die korrekte Verwendung der CSS-Float-Eigenschaft...
Inhaltsverzeichnis 1. MySQL-Datensicherung 1.1. m...
npm deinstallieren sudo npm deinstallieren npm -g...
Inhaltsverzeichnis 1. Übersicht 2. Routing Naviga...
Inhaltsverzeichnis Konzept Array-Destrukturierung...
In diesem Artikel finden Sie den spezifischen Cod...
MySQL Zeile zu Spalte, Spalte zu Zeile Der Satz i...
IFNULL(Ausdruck1,Ausdruck2) Wenn expr1 nicht NULL...
Aufschlag: # chkconfig --list Alle Systemdienste ...
Vorwort [root@localhost ~]# cat /etc/fstab # # /e...
Vorwort Wenn wir von Linux-Systemen sprechen, mei...
Unter Linux ist alles eine Datei (Verzeichnisse s...
In diesem Artikelbeispiel wird der spezifische Co...
1 Behalten Sie das RPM-Paket bei, das heruntergel...