nginx

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

Ubuntu 14.04 Trusty Tahr
Ubuntu 12.04 Precise Pangolin

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Installation von Programmen
Verwenden eines PPAs, optional
Archive entpacken, optional
Pakete aus dem Quellcode erstellen, optional
Ein Terminal öffnen
Einen Editor öffnen

Inhaltsverzeichnis

Installation
1. PPA
2. Manuell
Konfiguration
Steuerung von nginx
1. Mögliche Befehle
2. Andere Konfigurationsdatei verwenden
Optimierung von nginx
1. GZip-Komprimierung aktivieren
2. Charset festlegen
PHP mit nginx
Perl mit nginx
Module
Tipps & Tricks
Absicherung von nginx
Erste Hilfe bei Problemen
Links

nginx {en} (gesprochen „engine x”) ist ein Webserver, der im Vergleich zum Marktführer Apache sehr schnell und schlank ist. Er wurde mit der Vorgabe konzipiert, selbst unter hoher Last nur wenig Ressourcen zu verbrauchen. nginx wird von Igor Sysoev entwickelt und wird laut w3techs.com Statsitik {en} von ca. 30 % aller Websites genutzt (Stand: Sommer 2016). Damit ist nginx der am 2. meisten eingesetzte Webserver.

Installation¶

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

nginx (universe)

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:

ppa:nginx/stable

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.

Manuell¶

Da im Gegensatz zu Apache keine (nachladbaren) Module zum Einsatz kommen, werden benötigte Funktionen bereits beim Kompilieren von nginx angegeben. So kann man im Gegensatz zu den vorkompilierten Paketen aus den offiziellen Paketquellen oder dem PPA den Webserver noch genauer auf den geplanten Einsatzzweck abstimmen und weitere Performance-Gewinne erzielen. Bevor nginx kompiliert werden kann, werden folgende Pakete benötigt (je nach gewünschter Funktionalität evtl. auch noch weitere Pakete; Details sind dem nginx-Wiki {en} zu entnehmen):

build-essential (Basiswerkzeuge zur Kompilierung)
libpcre3-dev
libssl-dev (wird nur für SSL bzw. HTTPS benötigt)
zlib1g-dev

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install build-essential libpcre3-dev libssl-dev zlib1g-dev

sudo aptitude install build-essential libpcre3-dev libssl-dev zlib1g-dev

Dann wird der Quellcode von der offiziellen Downloadseite {en} {dl} benötigt. Nun entpackt ^[3] man das Quellcode-Archiv und kompiliert ^[4] nginx. Damit sich der selbst-kompilierte nginx (fast) wie eine Paket-Installation anfühlt, setzt man noch folgende symbolischen Links:

mkdir /etc/nginx
ln -s /usr/local/nginx/conf/nginx.conf /etc/nginx/nginx.conf
ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx

Somit spart man sich das umständliche Zusammensuchen der Komponenten und kann nginx direkt ohne Pfadangabe starten.

Wiki/Icons/settings.png

Konfiguration¶

nginx liest die Konfiguration aus der Datei /etc/nginx/nginx.conf. Diese besteht aus den Blöcken events { [...] } und http { [...] }. Kommentiert wird mit einer Raute (#).

Konfigurieren des Webservers¶

Grundkonfiguration¶

Damit nginx an eine Domain oder IP gebunden wird, muss folgender Grundblock in den http-Teil eingefügt werden:

server {

}

Hinweis:

Die Datei ist nach der Installation schon vorkonfiguriert. Es ist empfehlenswert, jegliche server { [...] }-Bereiche zu entfernen, um Komplikationen zu vermeiden.

Nun wird angegeben, an welchen Port sich nginx binden soll (80) und an welche Domain bzw. IP (localhost):

server {
     listen       80;
     server_name  localhost;
}

Alleine mit dieser Konfiguration ist nginx bereits erreichbar, hat aber keine Daten verfügbar, die an den Benutzer versendet werden können. Dies ändert man mit root (im Beispiel liegen die Dateien in /srv/localhost):

root         /srv/localhost;

Hinweis:

root steht für document root und nicht, wie man denken könnte, für den Benutzer root.

Zuletzt wird noch festgelegt, welche Datei aufgerufen werden soll, wenn der Nutzer nur localhost eintippt:

location / {
        index     index.html  index.htm;
}

Domains einbinden¶

Domains lassen sich folgendermaßen einbinden:

server_name  www.example.com example.com;

Damit hört nginx sowohl an www.example.com als auch example.com.

Sub- und Wildcarddomains einbinden¶

Sub- und Wildcarddomains bindet man mit

server_name  *.example.com subdomain.example.com;

ein.

Achtung!

Jede Domain, die in server_name aufgelistet ist, wird auch von dem (virtuellen) Server betrieben. Konkret würde dies für das Beispiel heißen, dass die beiden Domains mit dem gleichen Inhalt und den gleichen Einstellungen betrieben werden.

Beispiel¶

[...]

http {
     server {
          listen       80;
          server_name  localhost example.com www.example.com;
          root         /srv/daten;

          location / {
             index     index.html  index.htm;
          }
     }

     server {
          listen       80;
          server_name  subdomain.example.com;
          root         /srv/subdomain/daten;

          location / {
             index     index.html  index.htm;
          }
     }
}

[...]

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 wird aus. So ist z.B. im Python Umfeld der Einsatz von nginx als Reverse Proxy in Kombination mit den (lokal laufenden) WSGI Applikationsserver gunicorn oder uwsgi eine durchaus beliebte Lösung.

Im einfachsten Fall benötigt man in der 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.

Ändern der Umgebung¶

Ändern des Nutzers¶

Nginx kann - wie viele andere Webserver - auch einen anderen Nutzer als „root” benutzen. Um dies einzurichten, ändert man folgende Zeile:

#user  nobody;

ab zu folgender Zeile (in diesem Beispiel wird der Nutzer „www-data” verwendet):

user  www-data;

Dies ändert - unabhängig davon, mit welchem Nutzer nginx gestartet wurde - das Konto, mit dem der Daemon arbeitet.

Aktivierung einer Logdatei¶

Um eine komplette Logdatei nach /etc/nginx/logs/error.log zu schreiben, ändert man die Zeile:

#error_log  logs/error.log;

ab zu:

error_log  /etc/nginx/logs/error.log;

Durch das Hinzufügen von info oder notice nach dem Dateinamen kann das Protokoll gefiltert werden. Dies bedeutet, dass z.B. nur Informationen gesichert werden.

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]

Mögliche Befehle¶

Starten lässt sich nginx recht simpel:

sudo nginx

Es sind Rootrechte erforderlich, wenn nginx an einem Port kleiner als 1024 horchen soll (siehe auch Liste der standardisierten Ports).

Für das Stoppen übergibt man das "stop"-Signal an nginx:

sudo nginx -s stop

Falls ein Dienste-Skript vorhanden ist, kann man nginx auch mit diesen Optionen steuern:

/etc/init.d/nginx (start|stop|restart|reload|force-reload)

Andere Konfigurationsdatei verwenden¶

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

Optimierung von nginx¶

GZip-Komprimierung aktivieren¶

Dank der GZip-Komprimierung kann man sich viel Datenverkehr sparen. Wie die Kompression von Websites funktioniert und warum man sie aktivieren sollte, kann man auf betterexplained.com {en} nachlesen. nginx kann alle Typen von Websites und Textdateien komprimieren, im Gegensatz zu dem ZLib-Modul von PHP, welches nur PHP komprimiert.

Um die Komprimierung zu aktivieren, fügt man folgende Zeile in den http { [...] }-Block ein:

gzip on;

und startet nginx neu. Zusätzlich sollte man festlegen, welche Dateitypen geschrumpft werden sollen und welche Browser ausgenommen werden sollen:

gzip_types       text/plain application/xml;
gzip_disable     "MSIE [1-6]\.";

Charset festlegen¶

Falls ein Charset (=Zeichensatz) festgelegt werden soll, kann man sich mit folgendem Befehl im server { [...] }-Block behelfen:

charset         utf-8;

./php-logo.png

PHP mit nginx¶

FastCGI-Schnittstelle¶

nginx verlangt für PHP eine FastCGI-Schnittstelle. Da PHP nicht im Passiv-Modus agiert, müssen - wie bei FastCGI üblich - PHP-Instanzen gestartet werden, die im Arbeitsspeicher auf ihren Einsatz warten.

Zuerst installiert man PHP im CGI-Modus, falls noch nicht geschehen, mit folgendem Paket:

php5-cgi

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install php5-cgi

sudo aptitude install php5-cgi

Dann installiert man, falls noch nicht geschehen, das Paket

spawn-fcgi (universe)

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install spawn-fcgi

sudo aptitude install spawn-fcgi

Dann erstellt man ein Bash-Skript, welches die Instanzen startet (Quelle: Linode.com - Nginx and PHP-FastCGI on Ubuntu {en} ):

1 2	#!/bin/sh /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -f /usr/bin/php5-cgi

Das Skript speichert man unter /usr/local/bin/php-fastcgi ab und setzt mit

chmod a+x /usr/local/bin/php-fastcgi

die notwendigen Rechte. Man startet nun die Instanzen mit dem Befehl:

sudo php-fastcgi

Universelle Methode¶

Falls es Probleme geben sollte, kann man versuchen, PHP direkt an eine FastCGI-Schnittstelle zu binden. Dafür legt man die Datei /usr/local/bin/php-fastcgi mit folgendem Inhalt an:

1 2	#!/bin/bash php-cgi -b 127.0.0.1:9000

Danach vergibt man Ausführrechte:

chmod a+x /usr/local/bin/php-fastcgi

Und zu guter Letzt startet man die FastCGI-Schnittstelle mit dem Befehl:

sudo php-fastcgi

Die Konfiguration von nginx anpassen¶

Zu guter Letzt muss jetzt noch nginx wissen, wie man sich an die Schnittstelle bindet. Dazu fügt man in den server { [...] }-Block folgendes ein:

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

PHP mit dem Paket php5-fpm¶

Alternativ bietet sich der "FastCGI Process Manager" (kurz fpm) an, um PHP einfacher mit FastCGI einzubinden. Das Paket findet sich in den offiziellen Paketquellen:

php5-fpm (universe)

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren:

sudo apt-get install php5-fpm

sudo aptitude install php5-fpm

Fpm agiert als Dienst und die Konfiguration wird über /etc/php5/fpm/ vorgenommen. Den Service kann man mit:

sudo service php5-fpm restart

einfach neu starten bzw. stoppen/starten. Um PHP nun mit nginx zu nutzen, muss im Serverblock folgendes stehen:

location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi.config;  # fastcgi_params wird nur für Abwärtskompatibilität verwendet 
}

Diese Konfiguration kann auch entsprechend an eigene Bedürfnisse angepasst werden. Nach einem Neustart von nginx sollte PHP wie gewünscht funktionieren. Und durch die Verwendung von "Unix Domain Sockets" erspart man sich Probleme mit den Ports von FastCGI.

./camel_head.png

Perl mit nginx¶

Um Perl zum Laufen zu bekommen, ist einige Arbeit nötig: Zuerst einmal muss Perl überhaupt eine FastCGI-Schnittstelle bekommen. Das geht mit dem Befehl:

perl -MCPAN -e 'install FCGI'

Dann muss ein Perl-Skript geschrieben werden, über das Perl abläuft (Quelle {en} ):

#!/usr/bin/perl

use FCGI;
use Socket;
use POSIX qw(setsid);

require 'syscall.ph';

&daemonize;

#this keeps the program alive or something after exec'ing perl scripts
END() { } BEGIN() { }
*CORE::GLOBAL::exit = sub { die "fakeexit\nrc=".shift()."\n"; }; 
eval q{exit}; 
if ($@) { 
	exit unless $@ =~ /^fakeexit/; 
};

&main;

sub daemonize() {
    chdir '/'                 or die "Can't chdir to /: $!";
    defined(my $pid = fork)   or die "Can't fork: $!";
    exit if $pid;
    setsid                    or die "Can't start a new session: $!";
    umask 0;
}

sub main {
        $socket = FCGI::OpenSocket( "127.0.0.1:9000", 10 ); #use IP sockets
        $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, \%req_params, $socket );
        if ($request) { request_loop()};
            FCGI::CloseSocket( $socket );
}

sub request_loop {
        while( $request->Accept() >= 0 ) {
            
           #processing any STDIN input from WebServer (for CGI-POST actions)
           $stdin_passthrough ='';
           $req_len = 0 + $req_params{'CONTENT_LENGTH'};
           if (($req_params{'REQUEST_METHOD'} eq 'POST') && ($req_len != 0) ){ 
                my $bytes_read = 0;
                while ($bytes_read < $req_len) {
                        my $data = '';
                        my $bytes = read(STDIN, $data, ($req_len - $bytes_read));
                        last if ($bytes == 0 || !defined($bytes));
                        $stdin_passthrough .= $data;
                        $bytes_read += $bytes;
                }
            }

            #running the cgi app
            if ( (-x $req_params{SCRIPT_FILENAME}) &&  #can I execute this?
                 (-s $req_params{SCRIPT_FILENAME}) &&  #Is this file empty?
                 (-r $req_params{SCRIPT_FILENAME})     #can I read this file?
            ){
		pipe(CHILD_RD, PARENT_WR);
		my $pid = open(KID_TO_READ, "-|");
		unless(defined($pid)) {
			print("Content-type: text/plain\r\n\r\n");
                        print "Error: CGI app returned no output - ";
                        print "Executing $req_params{SCRIPT_FILENAME} failed !\n";
			next;
		}
		if ($pid > 0) {
			close(CHILD_RD);
			print PARENT_WR $stdin_passthrough;
			close(PARENT_WR);

			while(my $s = <KID_TO_READ>) { print $s; }
			close KID_TO_READ;
			waitpid($pid, 0);
		} else {
	                foreach $key ( keys %req_params){
        	           $ENV{$key} = $req_params{$key};
                	}
        	        # cd to the script's local directory
	                if ($req_params{SCRIPT_FILENAME} =~ /^(.*)\/[^\/]+$/) {
                        	chdir $1;
                	}

			close(PARENT_WR);
			close(STDIN);
			#fcntl(CHILD_RD, F_DUPFD, 0);
			syscall(&SYS_dup2, fileno(CHILD_RD), 0);
			#open(STDIN, "<&CHILD_RD");
			exec($req_params{SCRIPT_FILENAME});
			die("exec failed");
		}
            } 
            else {
                print("Content-type: text/plain\r\n\r\n");
                print "Error: No such CGI app - $req_params{SCRIPT_FILENAME} may not ";
                print "exist or is not executable by this process.\n";
            }

        }
}

Gespeichert wird das Perl-Skript unter /usr/local/bin/fastcgi-wrapper.pl. Die Schreibrechte müssen auch korrekt gesetzt werden:

chmod a+x /usr/local/bin/fastcgi-wrapper.pl

Zusätzlich wird noch ein Startskript erstellt, das als /usr/local/bin/perl-fastcgi gespeichert wird (Quelle {en} ):

#!/bin/bash
PERL_SCRIPT=/usr/bin/fastcgi-wrapper.pl
RETVAL=0
case "$1" in
    start)
      $PERL_SCRIPT
      RETVAL=$?
  ;;
    stop)
      killall -9 perl
      RETVAL=$?
  ;;
    restart)
      killall -9 perl
      $PERL_SCRIPT
      RETVAL=$?
  ;;
    *)
      echo "Usage: perl-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

Auch dieses Skript wird ausführbar gemacht:

chmod a+x /usr/local/bin/perl-fastcgi

Man startet nun die Schnittstelle mit dem Befehl:

perl-fastcgi start

Zuletzt muss nur noch die nginx-Konfiguration angepasst werden:

location ~ \.pl$ {
        include fastcgi.conf;
        fastcgi_pass  127.0.0.1:9000;
}

Hinweis:

GZip-Komprimierung verlangsamt die Skripte.

Module¶

nginx besitzt standardmäßig nur einige Module, welche hier {en} gelistet sind. Allerdings kann man nginx mit vielen weiteren Modulen benutzen, deren offiziellen Anlaufstellen hier {en} und hier {en} sind. Die Module kann man allerdings - nicht wie bei allen anderen Webservern - direkt benutzen, sondern muss sie mit nginx kompilieren^[4]. Wie das funktioniert, steht in aller Regel in der Dokumentation des Modules. Bei optionalen HTTP-Modulen (hier gelistet) funktioniert das folgendermaßen:

Im Beispiel wird SSL-Unterstützung installiert. Man bezieht sich den Quellcode (siehe Installation) von nginx und entpackt ihn. Statt nun

./configure

einzutippen, fügt man nun das Modul an:

./configure --with-http_ssl_module

Somit wird bei der weiteren Kompilierung SSL berücksichtigt. Um SSL zu benutzen, muss die Konfiguration angepasst werden, wie es im nginx-Wiki {en} beschrieben wird.

Tipps & Tricks¶

IPv6¶

Um nginx für IPv6 bereit zu machen, muss man zuerst - sofern man den Webserver nicht als Paket installiert hat - folgendermaßen neu kompilieren:

./configure --with-ipv6
make
sudo make install

Im zweiten Schritt öffnet man die Konfigurationsdatei und sorgt dafür, dass nginx IPv4- und IPv6-Verbindungen an Port 80 akzeptiert, indem man listen 80 durch listen [::]:80 ersetzt. Sofern noch nicht erledigt, müssen für jede Domain AAAA-Einträge in seinem DNS-Manager angelegt sein.

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.

Erste Hilfe bei Problemen¶

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               /srv/www/;
}

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               /srv/www/; # '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.

Da man das Problem mithilfe dieser Meldung nicht pauschal festmachen kann, gibt es hier {en} eine Liste von möglichen Ursachen und deren Behebung.

nginx verarbeitet keine .htaccess-Dateien¶

Das ist korrekt, da alle Änderungen bzw. Einstellungen in der Konfigurationsdatei nginx.conf vorgenommen werden. Und Absicht - div. 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 automatisch¶

Eventuell fehlt das /etc/init.d/-Startskript. Create an Init Script to Manage nginx {en} bietet Hilfe.

nginx startet nicht, da die Konfigurationsdatei angeblich falsch ist¶

Die Konfigurationsdatei überprüfen, ob überall am Ende jedes Befehls/jeder Zeile ein Semikolon ist, 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.

Wieso wird die neue Konfiguration nicht übernommen?¶

Für eine Konfigurationsänderung muss nginx neugestartet werden. Wie das geht, steht im Bereich "nginx steuern".

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¶

nginx Wiki - Dokumentation
SSL mit nginx benutzen
Sichere SSL/TLS Konfiguration mit Nginx - Ausführliche Anleitung
Apache vs Nginx: Web Server Performance Deathmatch
Hosting Websites with Nginx - Weiterführende Konfiguration
Certificate Pinning mit Nginx - Artikel zum "Public Key Pinning for HTTP" (RFC 7469)

Diese Revision wurde am 4. März 2017 08:03 von FHoernchen92 erstellt.

ubuntuusers.de

Wiki

nginx

Wiki

Mitmachen

Konfiguration

nginx

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

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Installation¶

PPA¶

Hinweis!

Manuell¶

Konfiguration¶

Konfigurieren des Webservers¶

Grundkonfiguration¶

Hinweis:

Hinweis:

Domains einbinden¶

Sub- und Wildcarddomains einbinden¶

Achtung!

Beispiel¶

nginx als Reverse-Proxy¶

Ändern der Umgebung¶

Ändern des Nutzers¶

Aktivierung einer Logdatei¶

Steuerung von nginx¶

Mögliche Befehle¶

Andere Konfigurationsdatei verwenden¶

Optimierung von nginx¶

GZip-Komprimierung aktivieren¶

Charset festlegen¶

PHP mit nginx¶

FastCGI-Schnittstelle¶

Universelle Methode¶

Die Konfiguration von nginx anpassen¶

PHP mit dem Paket php5-fpm¶

Perl mit nginx¶

Hinweis:

Module¶

Tipps & Tricks¶

IPv6¶

Loadbalancing mit nginx¶

Rewriting¶

Achtung!

Absicherung von nginx¶

Erste Hilfe bei Problemen¶

Bei allen PHP-Dateien wird nur "No input file specified" angezeigt¶

Ursache 1¶

Ursache 2¶

nginx zeigt bei existierenden Dateien im Browser "403" an¶

Es erscheint auf allen Websites nur noch die Meldung "502 Bad Gateway"¶

nginx verarbeitet keine .htaccess-Dateien¶

nginx startet nicht automatisch¶

nginx startet nicht, da die Konfigurationsdatei angeblich falsch ist¶

Obwohl nginx richtig konfiguriert ist, passiert beim Aufrufen von Subdomains nichts¶

Wieso bleibt nginx an der Meldung "[...]:80 failed (98: Address already in use)" hängen?¶

Wieso kann Plesk nginx nicht konfigurieren?¶

Wieso wird die neue Konfiguration nicht übernommen?¶

Die Log-Datei bleibt leer, warum?¶

Weshalb läuft eine FastCGI-Schnittstelle, die andere aber nicht?¶

Links¶