[[Vorlage(Getestet, bionic, focal)]] 

{{{#!vorlage Wissen
[:Pakete_installieren: Installation von Programmen] 
[:Paketquellen_freischalten/PPA: Verwenden eines PPAs] (''optional'')
[:Terminal: Ein Terminal öffnen] 
[:Editor: Einen Editor öffnen]
[:mit_Root-Rechten_arbeiten:]
}}}

[[Inhaltsverzeichnis(2)]] 

[[Bild(nginx-logo.png, 64, left)]]

[https://nginx.org nginx] {en} (gesprochen „engine x”) ist ein Webserver, der im Vergleich zu [:Apache:] (oder auch [wikipedia:Microsoft_Internet_Information_Services:IIS]) weniger Resourcen verbraucht und schnell ist. Aufgrund seiner eingebauten [wikipedia:Reverse_Proxy:Reverse-Proxy Funktionalität] wird nginx auch gerne als vorgeschalteter Webserver für dahinter liegende Applikationsserver genutzt.

nginx wird laut [https://w3techs.com/technologies/overview/web_server/all w3techs.com Statistik] {en} von ca. 40% aller Websites genutzt (Stand: September 2017). Damit ist nginx der am zweithäufigsten eingesetzte Webserver.

Neben der freien Version von nginx, welche auch unter eine [https://opensource.org/licenses/BSD-2-Clause freien Lizenz] {en} steht, gibt es auch eine kostenpflichtige Variante namens [https://www.nginx.com/products/nginx/ nginx Plus] {en}, für den die Firma nginx Inc. zusätzlichen Support und Module anbietet.

= Installation =
nginx kann aus den offiziellen Paketquellen installiert werden [1]:

{{{#!vorlage Paketinstallation
nginx
}}}

== PPA ==
Je nach eingesetzter Ubuntu-Version kann eine aktuellere nginx-Version über ein "Personal Package Archiv" (PPA) [2] erhältlich sein.
[[Vorlage(PPA, nginx/stable)]]

[[Bild(Wiki/Icons/settings.png, 48, align=right)]]
= Konfiguration =
Alle Konfigurationsdateien von nginx liegen im Verzeichnis '''/etc/nginx/''', die Grundkonfigurationsdatei ist '''nginx.conf'''. Diese besteht aus den Sektionen `events { [...] }` und `http { [...] }`. Kommentiert wird mit einer Raute (`#`). Jede Konfigurationszeile muss mit einem Semikolon `;` abgeschlossen werden.

In dieser Datei kann z.B. fest gelegt werden, mit welchen Rechten nginx läuft, in welche Dateien geloggt wird und auch die Verwendung von SSL kann hier konfiguriert werden.

Innerhalb der `http`-Sektionen können auch ein oder mehrere Sektionen `server { [...] }` angelegt werden, was im Kontext von nginx einem "virtuellen Server" entspricht (was das äquivalent zu "virtual hosts" beim Apache Server ist). In den `server` Sektionen erfolgt die Konfiguration von z.B. DocumentRoot, auf welcher IP-Adresse und auf welchem Port nginx lauscht, die Namensauflösung etc.

Es muss mindestens eine `server` Sektion vorhanden sein. Es können aber auch ohne weiteres mehrere Sektion aufgeführt werden. nginx arbeitet die `server` Sektionen von oben nach unten ab. Treffen die Bedingungen in der Sektion auf die Anfrage zu, werden die entsprechenden Daten ausgeliefert. Bei komplexen Konfigurationen sollte man deshalb auf die Reihenfolge der verschiedenen `server` Sektionen achten.

Standardmäßig werden diese Daten in einer oder mehreren Dateien im Verzeichnis '''/etc/nginx/sites-available''' abgelegt und aktiviert. Das Aktivieren geschieht dadurch, dass man einen [:ln:symbolische Link] der Datei '''/etc/nginx/sites-available/NAME_DER_DATEI''' nach '''/etc/nginx/sites-enabled/''' anlegt.

In der Standardinstallation ist bereits die Datei '''default''' vorhanden und aktiviert. Diese Datei kann man um eigene `server` Sektionen erweitern, wie im folgenden Beispiel gezeigt wird.

Zum Deaktivieren reicht es, den entsprechenden symbolischen Link aus dem Verzeichnis '''/etc/nginx/sites-enabled''' zu löschen.

== Konfiguration erweitern: Minimalbeispiel ===
Im folgenden Beispiel wird die vorhandene Konfigurationsdatei '''default''' um eine eigene Route erweitert, die eine einfache HTML-Seite ausgeben soll.

Dazu öffnet man die Datei '''default''' mit einem Editor mit Root-Rechten[4][5] und fügt nach der Zeile `server_name: _;`

die folgenden Zeilen ein:

{{{
        location /test {
                root /var/www/html/test;
		try_files $uri $uri/ =404;
        }
}}}

Erklärung:
 * Die erste Zeile legt fest, dass der folgenden Block an Direktiven für die Route `/test` gilt.
 * Die zweite Zeile legt das `root`-Verzeichnis, in dem nach (HTML-) Dateien gesucht wird, auf '''/var/www/html/test''' fest.
 * Die dritte Zeile besagt, dass ein "404 - not found" zurückgeliefert werden soll, wenn keine passende (HTML) Datei gefunden wurde.


Die Datei '''default''' sieht somit nach dem Hinzufügen (ohne Kommentarzeilen) wie folgt aus:

{{{
server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www/html;

	index index.html index.htm index.nginx-debian.html;

	server_name _;

        location /test {
                root /var/www/html/test;
		try_files $uri $uri/ =404;
        }

	location / {
		try_files $uri $uri/ =404;
	}
}
}}}

Jetzt muss man noch das Verzeichnis '''/var/www/html/test''' anlegen und darin eine HTML-Datei '''index.html''' erstellt werden.

Die geänderte Konfigurationsdatei wird mit dem folgenden Befehl auf Fehler getestet:

{{{#!vorlage Befehl
sudo nginx -t
}}}

Der Aufruf von `http://localhost/test` sollte jetzt die selbst angelegte HTML-Seite anzeigen.

Möchte man die Route `/test` in einer eigenen Konfigurationsdatei namens '''test''' hinterlegen, sollte die Datei so aussehen:

{{{
server {

    listen 80;
    listen [::]:80;

	root /var/www/html/test;
	index index.html;

	server_name test;

	location /test {
		try_files $uri $uri/ =404;
	}
}
}}}

Dann muss noch der symbolisch Link nach '''/etc/nginx/sites-enabled''' angelegt und die Konfiguration von nginx neu geladen werden:

{{{#!vorlage Befehl
sudo nginx -s reload
}}}


== nginx als Reverse-Proxy ==
Der nginx Webserver ist auch recht beliebt zum Einsatz als "Reverse Proxy". Dabei nimmt der Server die Anfrage aus dem Internet an, leitet diese an einen lokal laufenden Applikationsserver weiter und liefert anschließend dessen Antwort aus. So ist z.B. im [:Python:]-Umfeld der Einsatz von nginx als Reverse Proxy in Kombination mit dem (lokal laufenden) WSGI-Applikationsserver [:Gunicorn:] oder uwsgi eine durchaus beliebte Lösung.

Im einfachsten Fall benötigt man in der `server` Konfiguration von nginx nur die folgenden beiden Zeilen:

{{{
location / {
                proxy_pass http://127.0.0.1:8000;
}
}}}

Damit werden alle Anfragen an diese `location` - im obigen Beispiel als das Root-Verzeichnis der Domäne -  an `http://127.0.0.1:8000` weitergeleitet, wo dann ein Applikationsserver läuft.

Trotz der Weiterleitung übergibt nginx den angesteuerten Pfad (z.B. `http://example.com/neu`, und nicht `http://127.0.0.1:8000/`).

Weiterführende Informationen findet man in der [https://www.nginx.com/resources/admin-guide/reverse-proxy/ Dokumention] {en} des Servers.

= Steuerung von nginx =
Nginx bildet sich aus einem „Master”-Prozess und vielen „Slave”- bzw. „Client”-Prozessen. Man steuert nginx mit dem Master-Prozess, den man mit dem Befehl `nginx` anspricht. Dies geht nach folgendem Prinzip:

{{{#!vorlage Befehl
nginx [-s signal] [-c filename] [-p prefix] [-g directives]
}}}

Falls eine andere Konfigurationsdatei als '''/etc/nginx/nginx.conf''', z.B. zu Testzwecken, verwendet werden soll, startet man nginx folgendermaßen:

{{{#!vorlage Befehl
sudo nginx -c /pfad/der/konfigurationsdatei
}}}

Nützlich ist auch die Option `-t`, welche die Konfiguration von nginx testet. Nach jeder Änderung eine Konfigurationsdatei sollte man von daher 

{{{#!vorlage Befehl
sudo nginx -t
}}}

aufrufen und schauen, ob Fehler in einer der Konfigurationsdateien vorliegen. Wenn nicht, kann die Konfiguration neu eingelesen werden, so dass diese aktiv wird:

{{{#!vorlage Befehl
sudo nginx -s reload
}}}

Bei der Installation aus den Paketquellen wird nginx beim Systemstart über eine [:systemd:] Service Unit automatisch gestartet, welche über [:systemd/systemctl:systemctl] kontrolliert werden kann.

= Tipps & Tricks =
== Loadbalancing mit nginx ==
[wikipedia:Loadbalancing:] ist standardmäßig in nginx vorhanden und schlägt laut [https://www.robhost.de/adminblog/archives/227-Nginx-vs-Pound-Klarer-Sieg-fuer-Nginx-als-Loadbalancer.html diesem Artikel] {de} [wikipedia:Pound_(Software):Pound] deutlich. Im folgenden Beispiel verteilt nginx die Last auf 3 Server:
{{{
http {
  upstream loadbalancer {
    server 127.0.0.1:8000;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;    
  }
 
  server {
    listen 80;
    server_name www.example.com example.com;
    location / {
      proxy_pass http://loadbalancer;
    }
  }
}
}}}

Zur Erklärung: Im Upstream `loadbalancer` sind drei (Web-)Server vorhanden und mit ihren jeweiligen Daten (`IP:Port`) angegeben. Im `server { [...] }`-Block hört nginx an den Domains `www.example.com` und `example.com` an Port 80 und leitet die Anfrage an den upstream weiter.

== Rewriting ==
nginx unterstützt URL-Rewriting nativ und kann mithilfe von Regex ([wikipedia:Regulärer Ausdruck:]) Anfragen umschreiben. So kann zum Beispiel eine Domain `example.com/artikel.php?id=123` zu `example.com/artikel/123` vereinfacht werden, ohne dass der Nutzer weitergeleitet werden muss. Das Rewriting kann im Hintergrund auf Server-Ebene geschehen. Um Rewriting zu aktivieren, fügt man folgendes in seine Konfiguration in einem `server { [...] }`-Block ein:

{{{
rewrite  ^/artikel/(.*)$  /artikel.php?id=$1?  last;
}}}

Der reguläre Ausdruck `^/artikel/(.*)$` bedeutet folgendes: Existiert in der aufgerufenen Domain an irgendeiner Stelle die Zeichenfolge `/artikel/` wird sämtliches hinter dieser an `artikel.php` als GET-Parameter `id` übergeben.

Dieses Rewriting passiert mit der Flag `last` nur intern. nginx bietet folgende Flags zur Auswahl an:

{{{#!vorlage Tabelle
`last/break`
Internes Rewriting ohne Weiterleitung
+++
`redirect`
Leitet den Nutzer auf die Seite weiter (HTTP 302 - Temporäre Weiterleitung)
+++
`permanent`
Leitet den Nutzer auf die Seite weiter (HTTP 301 - Dauerhafte Weiterleitung)
}}}

{{{#!vorlage Warnung
Ohne eine gesetzte Flag gibt nginx den Fehler HTTP 500 zurück.
}}}

Weitere Hilfe, Tipps und Tricks findet man im [https://wiki.nginx.org/HttpRewriteModule nginx-Wiki] {en}.

= Absicherung von nginx =
Man stelle sich vor, ein Hacker würde eine Datei via PHP/Perl/Python in das Verzeichnis '''/uploads/''' hochladen. Diese Datei ist mit Schadcode infiziert und würde bei der Ausführung dem Server schaden. Wenn jetzt aber die Ausführung der Datei nicht verboten wird, könnte der Hacker seinen Angriff starten. Um das zu verhindern, fügt man in den `server { [...] }`-Block folgendes ein:

{{{
if ($uri !~ "^/uploads/") {
    fastcgi_pass 127.0.0.1:9000;
}
}}}

Dies löst aus, dass alle Dateien, die sonst über die FastCGI-Schnittstelle an Port 9000 laufen würden, in allen Ordnern mit dem Namen '''uploads''' nicht mehr ausgeführt werden.

= nginx mit anderen Programmiersprachen =
Die Nutzung von nginx in Kombination mit [:PHP:] ist im Artikel [:nginx/PHP:] beschrieben, die in Kombination mit [:Perl:] im Artikel [:nginx/Perl:].

= Probleme und Lösung =
[[Bild(Wiki/Icons/hint.png, 64, align=right)]]
Siehe auch [https://wiki.nginx.org/Pitfalls Nginx Pitfalls] {en} (sinngemäß: typische Fehler).

== Bei allen PHP-Dateien wird nur "No input file specified" angezeigt ==
Dies ist ein üblicher Fehler, der aber schnell behoben werden kann. Es gibt zwei hauptsächliche Ursachen:

=== Ursache 1 ===
Folgende Konfiguration wird für PHP-Dateien benutzt:
{{{
location ~ \.php$ {
        fastcgi_pass   localhost:9000;
        include           fastcgi_params; # Statt fastcgi.conf
}
}}}
Da nur in der Datei '''fastcgi.conf''' spezifiziert ist, dass PHP-Dateien auch unabhängig von dem `document root`-Verzeichnis verarbeitet werden sollen, sollte man diese statt `fastcgi_params` verwenden. Wer `fastcgi_params` trotzdem nutzen möchte, kann statt des Ersetzen folgende Zeile hinzufügen:
{{{
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}}}

=== Ursache 2 ===
Folgende (vereinfachte) Konfiguration wird benutzt:
{{{
location / {
        root               /var/www/html;
}

location ~ \.php$ {
        fastcgi_pass   localhost:9000;
        include          fastcgi.conf;
}
}}}
Da die location `~ \.php$` eine andere als `/` ist, ist für die FastCGI-Schnittstelle unbekannt, wo das Wurzelverzeichnis für diesen `server { [...] }`-Block ist, weil dieses nur in `location /` festgelegt ist. Folgende Konfiguration löst dieses Problem:

{{{
root               /var/www/html; # 'root' wird nun global für den server { [...] }-Block festgelegt

location ~ \.php$ {
                     fastcgi_pass   localhost:9000;
                     include          fastcgi.conf;
}
}}}

== nginx zeigt bei existierenden Dateien im Browser "403" an ==
Benutzerberechtigungen überprüfen! Diese Meldung kommt meistens, wenn nginx bzw. der Benutzer, mit dem nginx läuft, keinen Zugriff auf die Dateien hat.

== Es erscheint auf allen Websites nur noch die Meldung "502 Bad Gateway" ==
Dies passiert, wenn die FastCGI-Schnittstelle oder die Adresse von `proxy_pass` nicht für nginx erreichbar ist (auf Servern kann dies mit [:Lynx:] überprüft werden). Gründe können z.B. ein Absturz der Schnittstelle sein.

== nginx verarbeitet keine .htaccess-Dateien ==
Das ist korrekt, da alle Änderungen bzw. Einstellungen in der Konfigurationsdatei '''nginx.conf''' vorgenommen werden. Und Absicht - diverse Gründe, wieso es unter nginx keine htaccess-Dateien gibt, finden sich im [https://wiki.nginx.org/LikeApache-htaccess FAQ von nginx] {en} - kurz gesagt ist '''.htaccess''' ist ein Performancekiller und potentielle Sicherheitslücke. Allerdings gibt es diverse [https://winginx.com/htaccess Konverter] {en} von htaccess zu nginx, um den Umstieg leicht zu machen.

== nginx startet nicht, da die Konfigurationsdatei angeblich falsch ist ==
Die Konfigurationsdatei überprüfen, ob überall am Ende jedes Befehls/jeder Zeile ein Semikolon steht, und, ob alle `server { [...] }`-Blöcke auch mit dem Zeichen "}" geschlossen sind!

== Obwohl nginx richtig konfiguriert ist, passiert beim Aufrufen von Subdomains nichts ==
Bei diesem Problem wird vermutlich eine Fehlkonfiguration der DNS-Zonen vorliegen.

== Wieso bleibt nginx an der Meldung "[...]:80 failed (98: Address already in use)" hängen? ==
nginx oder ein anderer Webserver benutzt bereits den Port 80. Es kann immer nur ein Programm an dem Port lauschen.

== Wieso kann Plesk nginx nicht konfigurieren? ==
Das liegt daran, dass [wikipedia:Plesk:] [:Apache:] nutzt und nicht auf nginx zugeschnitten ist.

== Die Log-Datei bleibt leer, warum? ==
Falls der Nutzer geändert wurde, mit dem nginx läuft, muss dieser über Schreibzugriff auf diese Datei verfügen.

== Weshalb läuft eine FastCGI-Schnittstelle, die andere aber nicht? ==
Eventuell sollen beide Schnittstellen den selben Port verwenden. Allerdings kann sich jeweils nur eine Schnittstelle an einen Port binden.

= Links =
 * [https://wiki.nginx.org/ nginx Wiki] {en} - Dokumentation
 * [https://docs.nginx.com/nginx/ nginx Docs] {en} - Dokumentation für nginx Plus, welche aber auch in weiten Teil für die freie Variante von nginx zutrifft
 * [https://hg.nginx.org/nginx/ Quellcode Repositry] {en} von nginx bei Mercurial
 * [https://sherbers.de/howto/nginx/ Sichere SSL/TLS Konfiguration mit Nginx] {de} - Ausführliche Anleitung
 * [https://library.linode.com/web-servers/nginx/ Hosting Websites with Nginx] {en} - Weiterführende Konfiguration
 * [https://www.my-it-brain.de/wordpress/certificate-pinning-mit-nginx/ Certificate Pinning mit Nginx] {de} - Artikel zum "Public Key Pinning for HTTP" (RFC 7469)
 * [https://nhi1.selfhost.co/wiki/index.php?title=HOWTO_use_virtual_hosts_in_NGINX_to_run_multiple_web-application_on_a_single_server VHOST example] {en} - für das Heim-Netzwerk

#tag: Netzwerk, Internet, Server