Detaillierte Erklärung der Konfigurationsdatei nginx.conf

Nginx Die Konfigurationsdatei ist im Wesentlichen in vier Teile unterteilt: Hauptteil (globale Einstellungen), Serverteil (Hosteinstellungen), Upstreamteil (Upstream-Servereinstellungen, hauptsächlich Reverse-Proxy, Konfiguration im Zusammenhang mit dem Lastenausgleich) und Standortteil (Einstellungen, nachdem die URL einem bestimmten Standort entspricht). Die im Hauptteil festgelegten Anweisungen wirken sich auf die Einstellungen aller anderen Teile aus. Die Anweisungen im Serverteil werden hauptsächlich verwendet, um den Domänennamen, die IP-Adresse und die Portnummer des virtuellen Hosts festzulegen. Die Anweisungen im Upstreamteil werden verwendet, um eine Reihe von Back-End-Servern festzulegen, den Reverse-Proxy einzurichten und den Lastenausgleich der Back-End-Server durchzuführen. Der Standortteil wird verwendet, um dem Standort der Webseite zuzuordnen (z. B. dem Stammverzeichnis "/", "/images" usw.). Die Beziehung zwischen ihnen: Der Server erbt den Hauptteil, der Standort erbt den Server. Der Upstream erbt weder Anweisungen noch wird er vererbt.
nginx.conf Konfigurationsdateien
Nachfolgend finden Sie eine detaillierte Beschreibung der Konfigurationsdatei nginx.conf (die folgenden Konfigurationsparameter werden in vielen Fällen nicht unbedingt verwendet, sondern dienen nur als Referenz für die Beschreibung der Konfigurationsparameter. Die allgemeine Versionseinführung finden Sie weiter unten.)

# definiert den Benutzer und die Benutzergruppe, die Nginx ausführt Benutzer www www;

#nginx-Prozessnummer, normalerweise gleich der Anzahl der CPUs eingestellt
Arbeitsprozesse 4;

#-Prozess-PID-Datei
#pid-Protokolle/nginx.pid;

# gibt die maximale Anzahl von Deskriptoren an, die ein Prozess öffnen kann:
#-Arbeitsmodus und Obergrenze der Verbindungsanzahl
## Diese Anweisung bezieht sich auf die maximale Anzahl von Dateideskriptoren, die von einem nginx-Prozess geöffnet werden. Der theoretische Wert sollte der maximalen Anzahl geöffneter Dateien (ulimit -n) geteilt durch die Anzahl der nginx-Prozesse entsprechen. Da nginx die Anfragen jedoch nicht gleichmäßig verteilt, ist es am besten, den Wert von ulimit -n konsistent zu halten.
#Dies liegt daran, dass Nginx die Anforderungen während der Planung nicht gleichmäßig auf die Prozesse verteilt. Wenn Sie also 10240 eingeben und die Gesamtparallelität 30.000–40.000 erreicht, kann es sein, dass mehr als 10240 Prozesse vorhanden sind, und es wird ein 502-Fehler zurückgegeben.
worker_rlimit_nofile 65535;

Ereignisse {
#-Referenzereignismodell, verwenden Sie [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll-Modell
# ist ein leistungsstarkes Netzwerk-E/A-Modell im Linux-Kernel ab Version 2.6. Linux empfiehlt epoll. Unter FreeBSD verwenden Sie das kqueue-Modell.
# zusätzliche Anweisungen:
# ähnelt Apache. Nginx hat unterschiedliche Ereignismodelle für unterschiedliche Betriebssysteme.
#A) Standard-Ereignismodell
#Select und Poll gehören zum Standardereignismodell. Wenn es im aktuellen System keine effektivere Methode gibt, wählt Nginx Select oder Poll.
#B) Effizientes Ereignismodell
#Kqueue: Wird in FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 und MacOS X verwendet. Die Verwendung von kqueue auf MacOS X-Systemen mit zwei Prozessoren kann zu Kernel Panic führen.
#Epoll: wird im Linux-Kernel ab Version 2.6 verwendet.
#/dev/poll: wird unter Solaris 7 11/99+, HP/UX 11.22+ (Eventport), IRIX 6.5.15+ und Tru64 UNIX 5.1A+ verwendet.
#Eventport: wird in Solaris 10 verwendet. Um Kernel-Abstürze zu verhindern, ist die Installation von Sicherheitspatches erforderlich.
Verwenden Sie epoll

# Maximale Anzahl von Verbindungen für einen einzelnen Prozess (maximale Anzahl von Verbindungen = Anzahl der Verbindungen + Anzahl der Prozesse)
# wird entsprechend der Hardware angepasst und in Verbindung mit dem vorherigen Arbeitsprozess verwendet. Es sollte so groß wie möglich sein, aber den Becher nicht auf 100% laufen lassen.
Arbeiterverbindungen 1024;

#Keepalive-Timeout
keepalive_timeout 60;

#-Client-Anforderungsheader-Puffergröße. Diese kann entsprechend der System-Paging-Größe eingestellt werden. Normalerweise überschreitet die Größe eines Anforderungsheaders 1 KB nicht. Da das System-Paging jedoch in der Regel größer als 1 KB ist, wird hier die Paging-Größe eingestellt.
# Die Paging-Größe kann mit dem Befehl getconf PAGESIZE ermittelt werden.
#[root@web001 ~]# getconf PAGESIZE
# Es gibt jedoch Fälle, in denen die Client-Header-Buffer-Größe 4 KB überschreitet, der Wert der Client-Header-Buffer-Größe jedoch auf ein ganzzahliges Vielfaches der „System-Paging-Größe“ eingestellt werden muss.
Client-Header-Puffergröße 4k;

# gibt den Cache für geöffnete Dateien an. Standardmäßig ist er deaktiviert. „max“ gibt die Anzahl der Caches an. Es wird empfohlen, die Anzahl der geöffneten Dateien konsistent zu halten. „inactive“ bezeichnet die Zeit, nach der der Cache gelöscht wird, wenn die Datei nicht angefordert wird.
open_file_cache max=65535 inaktiv=60s;

# bezieht sich darauf, wie oft die zwischengespeicherten Informationen auf ihre Gültigkeit überprüft werden.
# Syntax: open_file_cache_valid Zeit Standardwert: open_file_cache_valid 60 Verwendet in: http, Server, Standort Diese Anweisung gibt an, wann die Gültigkeit von Cache-Elementen in open_file_cache überprüft werden soll.
open_file_cache_valid 80s;

#open_file_cache Die Mindestanzahl der Dateinutzungen innerhalb der inaktiven Parameterzeit der Direktive. Wird diese Anzahl überschritten, wird der Dateideskriptor immer im Cache geöffnet. Wird eine Datei beispielsweise innerhalb der inaktiven Zeit nicht einmal genutzt, wird sie entfernt.
# Syntax: open_file_cache_min_uses number Standardwert: open_file_cache_min_uses 1 Gültigkeitsbereich: http, Server, Standort Diese Direktive gibt die Mindestanzahl von Dateien an, die innerhalb eines bestimmten Zeitraums verwendet werden können, wenn die Direktive open_file_cache ungültig ist. Bei einem höheren Wert ist der Dateideskriptor immer im Cache geöffnet.
open_file_cache_min_uses 1;

# Syntax: open_file_cache_errors on | off Standardwert: open_file_cache_errors off Kontext: http, Server, Standort Diese Anweisung gibt an, ob Cache-Fehler bei der Suche nach einer Datei protokolliert werden sollen.
open_file_cache_errors ein;
}

# richtet einen HTTP-Server ein und nutzt dessen Reverse-Proxy-Funktion zur Unterstützung des Lastenausgleichs
http{
#-Dateierweiterungs- und Dateitypzuordnungstabelle
mime.types einschließen;

# Standarddateityp
Standardtyp Anwendung/Oktett-Stream;

# Standardkodierung
Zeichensatz UTF-8;

# Servername Hash-Tabellengröße
#Die Hash-Tabelle zum Speichern von Servernamen wird durch die Direktiven server_names_hash_max_size und server_names_hash_bucket_size gesteuert. Der Parameter Hash-Bucket-Größe entspricht immer der Größe der Hash-Tabelle und ist ein Vielfaches der Größe des Prozessor-Cache. Dadurch kann die Suche nach Hash-Tabellenschlüsseln im Prozessor beschleunigt und die Anzahl der Speicherzugriffe reduziert werden. Wenn die Hash-Bucket-Größe der Größe des Prozessor-Cache entspricht, beträgt die Anzahl der Speicherzugriffe beim Suchen eines Schlüssels im schlimmsten Fall 2. Der erste dient dazu, die Adresse der Speichereinheit zu bestimmen, der zweite, den Schlüsselwert in der Speichereinheit zu finden. Wenn Nginx also einen Hinweis gibt, dass die maximale Hash-Größe oder die Hash-Bucket-Größe erhöht werden soll, muss zunächst die Größe des ersteren Parameters erhöht werden.
Servernamen_Hash_Bucket_Größe 128;

# Die Puffergröße des Client-Anforderungsheaders. Diese kann entsprechend der Paging-Größe Ihres Systems eingestellt werden. Normalerweise überschreitet die Größe eines Anforderungsheaders 1 KB nicht. Da das System-Paging jedoch in der Regel größer als 1 KB ist, wird hier die Paging-Größe eingestellt. Die Paging-Größe kann mit dem Befehl getconf PAGESIZE ermittelt werden.
Client-Header-Puffergröße 32k;

#-Client-Anforderungsheaderpuffergröße. Standardmäßig verwendet nginx den Puffer client_header_buffer_size zum Lesen des Headerwerts. Ist der Header zu groß, wird large_client_header_buffers zum Lesen verwendet.
große_Client_Header_Puffer 4 64k;

# legt die Größe der über nginx hochgeladenen Dateien fest
Client_max_Körpergröße 8 m;

sendfile on; # aktiviert den effizienten Dateiübertragungsmodus. Die Direktive sendfile gibt an, ob nginx die Funktion sendfile zur Ausgabe von Dateien aufruft. Für normale Anwendungen ist die Direktive aktiviert. Wird sie für Downloads und andere Anwendungen mit hoher Festplatten-E/A-Last verwendet, kann sie deaktiviert werden, um die Festplatten- und Netzwerk-E/A-Verarbeitungsgeschwindigkeit auszugleichen und die Systemlast zu reduzieren. Hinweis: Sollte das Bild nicht normal angezeigt werden, deaktivieren Sie die Direktive.
Die Direktive #sendfile gibt an, ob nginx die Sendfile-Funktion (Zero-Copy-Modus) zur Ausgabe von Dateien aufruft. Für allgemeine Anwendungen muss sie aktiviert sein. Bei Anwendungen mit hoher Festplatten-E/A-Belastung, wie z. B. Downloads, kann sie deaktiviert werden, um die Festplatten- und Netzwerk-E/A-Verarbeitungsgeschwindigkeit auszugleichen und die Systemverfügbarkeit zu reduzieren.
sendfile an;

# öffnet den Zugriff auf die Verzeichnisliste, geeignet für Download-Server, standardmäßig geschlossen.
Autoindex aktiviert;

# Diese Option aktiviert oder deaktiviert die Verwendung der TCP_CORK-Option von socke. Diese Option wird nur bei Verwendung von sendfile verwendet.
tcp_nopush ein;

tcp_nodelay ein;

# langes Verbindungszeitlimit in Sekunden
keepalive_timeout 120;

Die mit #FastCGI verbundenen Parameter verbessern die Leistung der Website: Sie reduzieren den Ressourcenverbrauch und erhöhen die Zugriffsgeschwindigkeit. Die folgenden Parameter lassen sich anhand ihrer wörtlichen Bedeutung verstehen.
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;

#gzip-Moduleinstellungen
gzip an; # aktiviert die Gzip-Komprimierungsausgabe
gzip_min_length 1k; # minimale komprimierte Dateigröße
gzip_buffers 4 16k; # Komprimierungspuffer
gzip_http_version 1.0; #-Komprimierungsversion (Standard 1.1, wenn das Front-End Squid2.5 ist, verwenden Sie bitte 1.0)
gzip_comp_level 2; # Komprimierungsstufe
gzip_types text/plain application/x-javascript text/css application/xml; #-Komprimierungstyp, textml ist standardmäßig enthalten, daher ist es nicht nötig, es unten einzutragen. Es ist kein Problem, es einzutragen, es wird jedoch eine Warnung angezeigt.
gzip_vary an;

# muss verwendet werden, wenn die Anzahl der IP-Verbindungen begrenzt wird
#limit_Zone-Crawler $binary_Remote_Addr 10m;

#-Lastausgleichskonfiguration
Upstream piao.jd.com {

#Upstream-Lastausgleich, Gewicht ist das Gewicht, das entsprechend der Maschinenkonfiguration definiert werden kann. Der Gewichtsparameter stellt das Gewicht dar. Je höher das Gewicht, desto größer die Wahrscheinlichkeit der Zuweisung.
Server 192.168.80.121:80 Gewicht=3;
Server 192.168.80.122:80 Gewicht=2;
Server 192.168.80.123:80 Gewicht=3;

#nginx's Upstream unterstützt derzeit 4 Arten der Verteilung
#1, Polling (Standard)
# Jede Anfrage wird chronologisch nacheinander verschiedenen Backend-Servern zugewiesen. Wenn der Backend-Server ausfällt, kann er automatisch entfernt werden.
#2, Gewicht
# gibt die Polling-Wahrscheinlichkeit an. Die Gewichtung ist proportional zur Zugriffsrate und wird bei ungleichmäßiger Backend-Server-Performance verwendet.
#Beispiel:
#upstream gebacken {
#-Server 192.168.0.14 Gewicht=10;
#-Server 192.168.0.15 Gewicht=10;
#}
#2, ip_hash
# Jede Anfrage wird entsprechend dem Hash-Ergebnis der Zugriffs-IP zugewiesen, sodass jeder Besucher auf einen festen Backend-Server zugreift, wodurch das Sitzungsproblem gelöst werden kann.
#Beispiel:
#upstream gebacken {
# ip_hash;
#-Server 192.168.0.14:88;
#-Server 192.168.0.15:80;
#}
#3, fair (Drittanbieter)
# verteilt Anfragen basierend auf der Antwortzeit des Backend-Servers, wobei der Server mit der kürzesten Antwortzeit Priorität erhält.
#upstream-Backend {
#-Server Server1;
#-Server Server2;
# Messe;
#}
#4, url_hash (Drittanbieter)
# verteilt Anfragen entsprechend dem Hash-Ergebnis der aufgerufenen URL, sodass jede URL an denselben Backend-Server weitergeleitet wird. Dies ist effektiver, wenn der Backend-Server zwischengespeichert ist.
# Beispiel: Fügen Sie im Upstream eine Hash-Anweisung hinzu. Andere Parameter wie Gewicht können nicht in die Server-Anweisung geschrieben werden. „hash_method“ ist der verwendete Hash-Algorithmus.
#upstream-Backend {
#-Server Squid1:3128;
#-Server Squid2:3128;
#-Hash $-Anforderungs-URI;
# Hash-Methode crc32;
#}

#-Tipps:
#upstream-Bakeend{# definiert die IP und den Gerätestatus des Lastausgleichsgeräts}{
# ip_hash;
#-Server 127.0.0.1:9090 ausgefallen;
#-Server 127.0.0.1:8080 Gewicht=2;
#-Server 127.0.0.1:6060;
#-Server 127.0.0.1:7070-Sicherung;
#}
#Fügen Sie proxy_pass http://bakend/ zum Server hinzu, der Lastenausgleich verwenden muss;

# Der Status jedes Geräts wird wie folgt eingestellt:
#1.down bedeutet, dass der Server vor der Bestellung vorübergehend nicht an der Last teilnimmt
#2.weight Je größer das Gewicht, desto größer das Gewicht der Ladung.
#3.max_fails: Die Standardanzahl zulässiger Anforderungsfehler beträgt 1. Wenn die maximale Anzahl überschritten wird, wird ein vom Modul proxy_next_upstream definierter Fehler zurückgegeben.
#4.fail_timeout: Die Pausenzeit nach max_fails-Fehlern.
#5.backup: Wenn alle anderen Nicht-Backup-Rechner ausgefallen oder ausgelastet sind, wird der Backup-Rechner angefordert. Dadurch wird dieser Rechner am wenigsten belastet.

#nginx unterstützt die gleichzeitige Einrichtung mehrerer Lastausgleichsgruppen zur Verwendung durch verschiedene Server.
#client_body_in_file_only ist auf On gesetzt, um die vom Client gesendeten Daten zum Debuggen in einer Datei aufzuzeichnen
#client_body_temp_path legt das Verzeichnis der Datensatzdatei fest. Sie können bis zu 3 Verzeichnisebenen festlegen
#location stimmt mit der URL überein. Es kann eine Umleitung oder einen neuen Proxy-Lastausgleich durchführen.
}

# virtuelle Hostkonfiguration
Server {
#-Abhörport
hören Sie 80;

Es können mehrere #-Domänennamen vorhanden sein, getrennt durch Leerzeichen
Servername www.jd.com jd.com;
# Standardeintragsdateiname
index index.html index.htm index.php;
Wurzel /data/www/jd;

# führt Lastausgleich auf ****** durch
Standort ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi.conf einschließen;
}

# Bild-Cache-Zeiteinstellung
Standort ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
läuft in 10 Tagen ab;
}

#JS- und CSS-Cache-Zeiteinstellungen
Standort ~ .*.(js|css)?$
{
läuft nach 1 Stunde ab;
}

#-Protokollformateinstellung
#$remote_addr und $http_x_forwarded_for werden verwendet, um die IP-Adresse des Clients aufzuzeichnen;
#$remote_user: wird zum Aufzeichnen des Client-Benutzernamens verwendet;
#$time_local: wird zum Aufzeichnen der Zugriffszeit und Zeitzone verwendet;
#$request: wird verwendet, um die angeforderte URL und das HTTP-Protokoll aufzuzeichnen;
#$status: Wird verwendet, um den Anforderungsstatus aufzuzeichnen. Erfolg ist 200.
#$body_bytes_sent: zeichnet die Größe des an den Client gesendeten Dateitexts auf;
#$http_referer: wird verwendet, um den Seitenlink aufzuzeichnen, von dem der Besuch kam;
#$http_user_agent: zeichnet relevante Informationen des Client-Browsers auf;
# Normalerweise befindet sich der Webserver hinter dem Reverse-Proxy und kann daher die IP-Adresse des Clients nicht ermitteln. Die über $remote_add ermittelte IP-Adresse ist die IP-Adresse des Reverse-Proxy-Servers. Der Reverse-Proxy-Server kann in den HTTP-Header-Informationen der weitergeleiteten Anfrage x_forwarded_for-Informationen hinzufügen, um die IP-Adresse des ursprünglichen Clients und die vom ursprünglichen Client angeforderte Serveradresse aufzuzeichnen.
log_format Zugriff '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
„$http_user_agent“ $http_x_forwarded_for“;

# definiert das Zugriffsprotokoll dieses virtuellen Hosts
Zugriffsprotokoll /usr/local/nginx/logs/host.access.log main;
Zugriffsprotokoll /usr/local/nginx/logs/host.access.404.log log404;

# Reverse-Proxy für „/connect-controller“ aktivieren
Standort /Connect-Controller {
proxy_pass http://127.0.0.1:88; #Bitte beachten Sie, dass die Portnummer hier nicht mit der vom virtuellen Host abgehörten Portnummer (d. h. dem vom Server abgehörten Port) übereinstimmen darf.
Proxy_Redirect aus;
proxy_set_header X-Real-IP $remote_addr;

Der #-Backend-Webserver kann die tatsächliche IP des Benutzers über X-Forwarded-For abrufen
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;

# Im Folgenden sind einige optionale Reverse-Proxy-Konfigurationen aufgeführt.
proxy_set_header Host $host;

# Die maximale Anzahl von Bytes einer einzelnen Datei, die ein Client anfordern darf
Client_max_Körpergröße 10 m;

# Die maximale Anzahl an Bytes, die der Proxy für Clientanforderungen puffert.
#Wenn Sie einen relativ großen Wert wie 256 KB festlegen, ist dies normal, unabhängig davon, ob Sie mit Firefox oder IE Bilder mit einer Größe unter 256 KB senden. Wenn Sie diese Anweisung kommentieren und die Standardeinstellung „client_body_buffer_size“ verwenden, die der doppelten Seitengröße des Betriebssystems entspricht (8 KB oder 16 KB), treten Probleme auf.
# Ob Sie Firefox 4.0 oder IE 8.0 verwenden, das Senden eines relativ großen Bildes von etwa 200 KB führt zu einem 500 Internal Server Error
Client-Body-Puffergröße 128 KB;

# weist nginx an, HTTP-Antwortcodes von 400 oder höher zu blockieren.
proxy_intercept_errors ein;

# Backend-Server-Verbindungs-Timeout_Handshake einleiten und auf Antwort-Timeout warten
Nginx-Verbindungstimeout mit Backend-Server (Proxy-Verbindungstimeout)
Proxy-Verbindungs-Timeout 90;

Datenübertragungszeit des Backend-Servers (Sende-Timeout des Agenten)
# Backend-Server-Datenübertragungszeit_ bedeutet, dass der Backend-Server alle Daten innerhalb der angegebenen Zeit übertragen muss
Proxy_Sendezeitüberschreitung 90;

Nach erfolgreicher Verbindung die Antwortzeit des Backend-Servers (Proxy-Empfangs-Timeout)
Nachdem # erfolgreich eine Verbindung hergestellt hat, entspricht die Zeit, die zum Warten auf die Antwort des Back-End-Servers benötigt wird, tatsächlich der Zeit, die es in die Back-End-Warteschlange gelangt ist und auf die Verarbeitung wartet (man kann auch sagen, dass es sich um die Zeit handelt, die der Back-End-Server benötigt, um die Anforderung zu verarbeiten).
Proxy_Lese_Timeout 90;

# legt die Puffergröße zum Speichern von Benutzerheaderinformationen im Proxyserver (nginx) fest.
# legt die Puffergröße für den ersten Teil der vom Proxy-Server gelesenen Antwort fest. Normalerweise enthält dieser Teil der Antwort einen kleinen Antwortheader. Standardmäßig entspricht dieser Wert der Größe des in der Direktive proxy_buffers angegebenen Puffers, kann aber auch kleiner eingestellt werden.
Proxy-Puffergröße 4k;

#proxy_buffers-Puffer, die durchschnittliche Webseite ist unter 32k eingestellt
# legt die Anzahl und Größe der Puffer fest, die zum Lesen der Antworten (vom Proxy-Server) verwendet werden. Der Standardwert ist auch die Paging-Größe, die je nach Betriebssystem 4 KB oder 8 KB betragen kann.
Proxy-Puffer 4 32k;

# Puffergröße bei hoher Belastung (proxy_buffers*2)
Proxy_Busy_Buffer_Größe 64k;

# legt die Größe der Daten beim Schreiben in proxy_temp_path fest, um zu verhindern, dass ein Arbeitsprozess beim Übergeben von Dateien zu lange blockiert wird
# Legt die Größe des Cache-Ordners fest. Wenn dieser Wert überschritten wird, wird er vom Upstream-Server übertragen.
Proxy_Temp_File_Schreibgröße 64k;
}

# lokale dynamische und statische Trennung der Reverse-Proxy-Konfiguration
# Alle JSP-Seiten werden von Tomcat oder Resin verwaltet
Standort ~ .(jsp|jspx|do)?$ {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
Proxy-Passwort http://127.0.0.1:8080;
}
}
}

Allgemeine Nginx-Konfigurationsdatei (hier ist die nginx.conf-Konfiguration unter nginx1.14.2 auf einem Windows-System)
Die folgende Datei nginx.conf implementiert einfach ein Beispiel von nginx als Reverse-Proxy-Server am Front-End, der statische Dateien wie js und png verarbeitet und dynamische Anforderungen wie jsp an andere Server weiterleitet (eine detaillierte Erklärung der relevanten Konfigurationsparameter finden Sie in der obigen Erklärung):
Arbeitsprozesse 1;

#error_log Protokolle/Fehler.log;
#error_log logs/error.log-Hinweis;
#error_log Protokolle/error.log-Informationen;

#pid-Protokolle/nginx.pid;

Ereignisse {
Arbeiterverbindungen 1024;
}

http {
mime.types einschließen;
Standardtyp Anwendung/Oktett-Stream;

#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';

access_log Protokolle/access.log Haupt;
error_log Protokolle/ssl.error.log crit;

sendfile an;
#tcp_nopush ein;

#keepalive_timeout 0;
keepalive_timeout 65;

#gzip an;

Server {
hören Sie 8088;
Servername localhost;

Zeichensatz UTF-8;

#access_log Protokolle/host.access.log Haupt;

#-Eintragsdateieinstellungen
Standort / {
Stammverzeichnis D:/vueWork/dentalFactory/dist; #-Eintragsdateiverzeichnis
index index.html index.htm; # Standardeintragsdateiname
}

# Tomcat Reverse-Proxy-Konfiguration
Standort /Standortname/ {
proxy_pass http://192.168.1.10:8080; # http://127.0.0.1:8080/Dienstname (Projektname)/
#proxy_set_header Host $host;
proxy_set_header Host $host:$server_port; //Hinweis: Wenn die Portnummer des aktuellen Projekts nicht 8080 ist, ist diese Konfiguration erforderlich, da das Backend sonst nicht die richtige Portnummer abrufen kann
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
}

#-Proxy-Konfiguration statischer Ressourcen (im Allgemeinen ist keine Konfiguration erforderlich, hier ist ein Beispiel für die Konfiguration von Bildressourcen)
#location /images/ {
#-Stammverzeichnis D:/A-studySpace/nginxDemo;
#}

1TP5Hier konfigurieren Sie die 404-Seite
#error_Seite 404 /404.html;

# Dies ist der entsprechende Seitenkonfigurationsort für den Anforderungsstatus
Fehlerseite 500 502 503 504 /50x.html;
Standort = /50x.html {
Stamm-HTML;
}

# PHP-Reverse-Proxy-Konfiguration
# leitet alle PHP-Seitenanfragen zur Verarbeitung an php-fpm weiter
#location ~ \.php$ {
#-Stamm-HTML;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; #fastcgi_param hat viele Konfigurationsparameter, passen Sie diese nach Bedarf an
# enthält fastcgi_params;
#}

}

# ein weiterer virtueller Host, der eine Mischung aus IP-, Namens- und Port-basierter Konfiguration verwendet
#
#server {
# hören 8000;
# hört somename:8080;
# Servername irgendein Alias anderer Alias;

# Standort / {
#-Stamm-HTML;
#-Index index.html index.htm;
# }
#}

# HTTPS-Server
#
#server {
# hören 443 SSL;
# Servername lokaler Host;

# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;

# ssl_session_cache geteilt:SSL:1m;
# ssl_session_timeout 5m;

# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers ein;

# Standort / {
#-Stamm-HTML;
#-Index index.html index.htm;
# }
#}

}

Punktzahl