PPA¶

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

Adresszeile zum Hinzufügen des PPAs:

• ppa:nginx/stable

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:

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:

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 🇬🇧 des Servers.

Loadbalancing mit nginx¶

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

Weitere Hilfe, Tipps und Tricks findet man im nginx-Wiki 🇬🇧.

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:

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

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

location / {
        root               /var/www/html;
}

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

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 🇬🇧 - kurz gesagt ist .htaccess ist ein Performancekiller und potentielle Sicherheitslücke. Allerdings gibt es diverse Konverter 🇬🇧 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.