nginx

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

  1. Installation von Programmen

  2. Verwenden eines PPAs, optional

  3. Ein Terminal öffnen

  4. Einen Editor öffnen

  5. mit Root-Rechten arbeiten

Inhaltsverzeichnis
  1. Installation
    1. PPA
  2. Konfiguration
    1. Konfiguration erweitern: Minimalbeispiel...
    2. nginx als Reverse-Proxy
  3. Steuerung von nginx
  4. Tipps & Tricks
    1. Loadbalancing mit nginx
    2. Rewriting
  5. Absicherung von nginx
  6. nginx mit anderen Programmiersprachen
  7. Probleme und Lösung
    1. Bei allen PHP-Dateien wird nur "No input...
    2. nginx zeigt bei existierenden Dateien im...
    3. Es erscheint auf allen Websites nur noch...
    4. nginx verarbeitet keine .htaccess-Dateie...
    5. nginx startet nicht, da die Konfiguratio...
    6. Obwohl nginx richtig konfiguriert ist, p...
    7. Wieso bleibt nginx an der Meldung "[...]...
    8. Wieso kann Plesk nginx nicht konfigurier...
    9. Die Log-Datei bleibt leer, warum?
    10. Weshalb läuft eine FastCGI-Schnittstelle...
  8. Links

nginx-logo.png

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

nginx wird laut 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 freien Lizenz {en} steht, gibt es auch eine kostenpflichtige Variante namens 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]:

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install nginx 

sudo aptitude install nginx 

PPA

Eine – je nach eingesetzter Ubuntu-Version – aktuellere nginx-Version ist über ein "Personal Package Archiv" (PPA) [2] erhältlich.

Adresszeile zum Hinzufügen des PPAs:

Hinweis!

Zusätzliche Fremdquellen können das System gefährden.


Ein PPA unterstützt nicht zwangsläufig alle Ubuntu-Versionen. Weitere Informationen sind der Wiki/Vorlagen/PPA/ppa.png PPA-Beschreibung des Eigentümers/Teams nginx zu entnehmen.

Damit Pakete aus dem PPA genutzt werden können, müssen die Paketquellen neu eingelesen werden.

Wiki/Icons/settings.png

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.

Eine server Sektion muss vorhanden sein, es können aber ohne weiteres auch 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 Konfiguration sollte man von daher auf die Reihenfolge der verschiedenen server Sektionen achten.

Standardmäßig werden aber diese Daten in ein oder mehreren Dateien im Verzeichnis /etc/nginx/sites-available abgelegt und aktiviert. Das Aktivierten geschieht dadurch, dass man eine symbolische Link der Datei in /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 jetzt um eigene server Sektionen erweitert und man legt eigene Dateien an, wie im folgenden Beispiel.

Zur Deaktivierung reicht es, einfach den entsprechend symbolischen Link in im Verzeichnis /etc/nginx/sites-enabled zu löschen.

Konfiguration erweitern: Minimalbeispiel

Im folgenden Beispiel wird die vorhandene Konfigurationsdatei default um eine eigene Route erweitet, 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 komplette Datei default sieht dann komplett (ohne Kommentarzeilen) so 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 Konfiguration kann noch auf Fehler getestet werden:

sudo nginx -t 

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

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:

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 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:

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:

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

sudo nginx -t 

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

sudo nginx -s reload 

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

Tipps & Tricks

Loadbalancing mit nginx

Loadbalancing ist standardmäßig in nginx vorhanden und schlägt laut diesem Artikel {de} 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 (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:

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)

Achtung!

Ohne eine gesetzte Flag gibt nginx den Fehler HTTP 500 zurück.

Weitere Hilfe, Tipps und Tricks findet man im 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

Wiki/Icons/hint.png Siehe auch 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 FAQ von nginx {en} - kurz gesagt ist .htaccess ist ein Performancekiller und potentielle Sicherheitslücke. Allerdings gibt es diverse 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 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.