# NGINX-Tutorial: Die grundlegenden Befehle und Konfigurationen In unserem Grundlagen-Artikel “[NGINX – der schnelle und ressourcenschonende Webserver](https://www.ionos.de/digitalguide/server/konfiguration/nginx-grundlagen-installation-und-einrichtung/ "NGINX: Grundlagen, Installation und Einrichtung")” haben wir bereits für Sie zusammengefasst, was NGINX ausmacht und wie Sie es auf Ihrem System installieren und einrichten. In dem folgenden Tutorial bieten wir Ihnen einen Überblick über die grundlegenden Befehle und Konfigurationsmöglichkeiten der modernen Webserver-Software. ## Die zentrale Steuereinheit: nginx.conf NGINX arbeitet anders als beispielsweise Apache eventbasiert. Einzelne Anfragen werden nicht jeweils als neuer Arbeitsprozess eingestuft, für den sämtliche Module geladen werden müssen, sondern als Event. Diese **Events werden** **auf existierende Arbeitsprozesse aufgeteilt**, die durch den übergeordneten Hauptprozess aufrechterhalten werden. Wie viele Arbeitsprozesse letztendlich existieren und auf welche Art und Weise die Serveranfragen (also die Events) aufgeteilt werden, ist in der Konfigurationsdatei *nginx.conf* definiert. Diese finden Sie standardmäßig in den Verzeichnissen */usr/local/nginx/conf*, */etc/nginx* oder */usr/local/etc/nginx*. ## Prozesse verwalten und neue Konfigurationen übernehmen NGINX startet nach der Installation automatisch, was Sie alternativ aber auch mithilfe des folgenden Befehls in die Wege leiten können: ```none sudo service nginx start ``` Läuft die Webserver-Software, kontrollieren Sie diese, indem Sie die Prozesse (in erster Linie den Hauptprozess) mit dem Parameter -s und einem bestimmten Signal ansprechen. Die Syntax der entsprechenden Befehle ist relativ unspektakulär: ```none sudo nginx -s signal ``` Für „signal“ haben Sie unter anderem die folgenden vier Möglichkeiten: - **stop**: NGINX wird sofort beendet. - **quit**: NGINX wird beendet, nachdem alle aktive Anfragen beantwortet worden sind. - **reload**: Die Konfigurationsdatei wird neu geladen. - **reopen**: Die Log-Files werden neu gestartet. Die Reload-Option, mit der die Konfigurationsdatei neu geladen wird, ist eine gute Möglichkeit, um Veränderungen an selbiger zu übernehmen, ohne die Webserver-Software beenden und neustarten zu müssen. In jedem Fall müssen Sie sich für eine Variante – **Komplett-Neustart des Servers oder einen einfachen NGINX-Reload** – entscheiden, damit die Änderungen übernommen werden. Wenn Sie sich für letztere, elegantere Version entschieden und den untenstehenden Befehl ausgeführt haben, erhält der Hauptprozess die Anweisung, die Änderungen in der *nginx.conf*-Datei zu übernehmen: ```none sudo nginx -s reload ``` Zu diesem Zweck wird zunächst die Korrektheit der Syntax überprüft. Bei positiver Rückmeldung startet der Hauptprozess neue Arbeitsprozesse mit den neuen Einstellungen und initiiert gleichzeitig den Stopp der alten Prozesse. Schlägt die **Validierung der Syntax** fehl, wird der alte Konfigurationsstand beibehalten. Alle aktiven Arbeitsprozesse werden beendet, sobald sämtliche aktiven Anfragen bearbeitet wurden. Im Übrigen können Sie NGINX-Prozesse auch ganz gezielt mithilfe von Tools wie kill ansprechen. Sie benötigen lediglich die entsprechende Prozess-ID, die Sie in der *nginx.pid*-Datei im Verzeichnis */usr/local/nginx/logs* oder alternativ im Verzeichnis */var/run* finden. Hat der Hauptprozess zum Beispiel die ID 1628, kann er mit kill und dem Quit-Signal im Schongang beendet werden: ```none sudo kill -s quit 1628 ``` Mit dem Dienstprogramm ps können Sie sich darüber hinaus eine Liste aller ausgeführten NGINX-Prozesse anzeigen lassen: ```none sudo ps -ax | grep nginx ``` ## So regeln Sie die Auslieferung statischer Inhalte Mit großer Wahrscheinlichkeit nutzen Sie Ihren Webserver, um Dateien wie Bilder, Videos oder statische HTML-Inhalte auszuliefern. Aus Gründen der Effizienz bietet es sich an, verschiedene **lokale Verzeichnisse für die unterschiedlichen Inhaltstypen** zu wählen. Beginnen Sie damit, das exemplarische Verzeichnis */data/html* anzulegen und dort ein beispielhaftes HTML-Dokument *index.html* zu platzieren sowie einen Ordner */data/bilder* mitsamt einigen Beispielbildern zu erzeugen. Im nächsten Schritt müssen die beiden Verzeichnisse in der Konfigurationsdatei eingetragen werden, indem man beide in der Server-Block-Direktive festhält, die ihrerseits Sub-Direktive der Http-Block-Direktive ist. Standardmäßig sind hier bereits verschiedene Anweisungen festgehalten, die Sie zunächst ausschalten können (off). Legen Sie anschließend einfach eine separate Server-Block-Anweisung an: ```none http { server { } } ``` In diesem Server-Block sollen nun die beiden Verzeichnisse angegeben werden, in denen Bilder und HTML-Dokumente liegen. Das entsprechende Resultat sieht folgendermaßen aus: ```none server { location / { root /data/html; } location /bilder/ { root /data; } } ``` Bei dieser Konfiguration handelt es sich um eine Standardeinstellung eines Servers, der auf Port 80 lauscht und über den [Localhost](https://www.ionos.de/digitalguide/server/knowhow/localhost/ "Localhost") zugänglich ist. Alle Anfragen, deren **URIs** mit */bilder/* beginnen, werden nun Dateien aus dem */data/bilder*-Verzeichnis anfordern. Existiert entsprechende Datei dort nicht, erscheint eine Fehlermeldung. Alle NGINX-Events, deren URIs hingegen nicht mit */bilder/* beginnen, werden in das */data/html*-Verzeichnis weitergeleitet. Denken Sie daran, NGINX im Anschluss neu zu laden oder neu zu starten, um die Änderungen zu übernehmen. ## Einrichtung eines einfachen NGINX-Proxy-Servers Sehr häufig wird NGINX zum Betreiben eines [Proxy-Servers](https://www.ionos.de/digitalguide/server/knowhow/was-ist-ein-proxy-server/) eingesetzt, um anstelle des eigentlichen Servers eingehende Anfragen entgegenzunehmen, diese nach verschiedensten Kriterien zu filtern und weiterzuleiten sowie die jeweilige Antwort an die Clients auszuliefern. Besonders beliebt sind **Cache-Proxys**, die lokal gespeicherte, statische Inhalte direkt ausliefern und nur alle weiteren Anfragen an den Server weiterleiten. Ebenfalls sehr verbreitet sind **Firewall-Proxys**, die unsichere bzw. unerwünschte Verbindungen herausfiltern. Im folgenden Beispiel geht es um den erstgenannten Cache-Proxy, der angeforderte Bilder aus dem lokalen Verzeichnis ausspielen und alle weiteren Anfragen an den Webserver weiterleiten soll. Im ersten Schritt definieren Sie in der *nginx.conf* den Hauptserver: ```none server { listen 8080; root /data/up1; location / { } } ``` Im Gegensatz zum vorherigen Beispiel nutzen Sie hierbei die **Listen-Direktive**, da nicht der Standard-Port, sondern Port 8080 für eingehende Anfragen genutzt werden soll. Legen Sie außerdem das angepeilte Verzeichnis */data/up1* an und dort die *index.html*-Seite ab. Als zweites werden der Proxy-Server und seine Funktion, **Bildinhalte auszuliefern**, definiert, indem die Proxy-pass-Direktive inklusive der Angaben über den Hauptserver – Protokoll (*http*), Name (*localhost*) und Port (*8080*) – zum Einsatz kommt: ```none server { location / { proxy_pass http://localhost:8080; } location ~ \.(gif|jpg|png) $ { root /data/bilder; } } ``` Der zweite **Location-Block** weist den Proxy-Server an, alle Anfragen selbst zu beantworten, deren URIs auf den bildertypischen Endungen *.gif*, *.jpg* und *.png* enden, indem der entsprechende Inhalt aus dem lokalen Verzeichnis */data/bilder* abgerufen wird. Alle anderen Anfragen werden zum Hauptserver weitergeleitet. Wie auch bei den Einstellungen zuvor, speichern Sie Ihren **Bilder-Proxy** per Reload-Signal an den Hauptprozess bzw. mit einem Restart von NGINX. Weitere mögliche Direktiven für komplexere Proxy-Einstellungen finden Sie im [offiziellen NGINX-Onlinehandbuch](https://nginx.org/en/docs/http/ngx_http_proxy_module.html "nginx.org – Alle verfügbaren Proxy-Direktiven auf einen Blick"). This is a markdown version of: [https://www.ionos.de/digitalguide/server/konfiguration/nginx-tutorial-erste-schritte-mit-der-nginxconf/](https://www.ionos.de/digitalguide/server/konfiguration/nginx-tutorial-erste-schritte-mit-der-nginxconf/) for AI/LLM consumption.