Was ist Nginx und wofür wird es eingesetzt?

• Server und Infrastruktur
• Aktualisiert: 04.10.2026
• Ca. 9 Min. Lesezeit

Nginx kennenlernen

1. 1

   Die vier Rollen von Nginx

   Dieselbe Software übernimmt je nach Konfiguration unterschiedliche Aufgaben. In den meisten Installationen werden mehrere dieser Rollen gemeinsam genutzt.

   • Webserver: Liest statische Dateien wie HTML, CSS, JavaScript und Bilder direkt von der Festplatte und sendet sie an den Besucher.
   • Reverse Proxy: Beantwortet die Anfrage nicht selbst, sondern leitet sie an eine dahinterliegende Anwendung (den Backend-Server) weiter und bringt die Antwort zum Besucher zurück. PHP-, Node.js-, Python- oder Java-Anwendungen werden meist auf diese Weise veröffentlicht. Näheres: Was ist ein Reverse Proxy?
   • Load Balancer: Betreiben mehrere Server dieselbe Anwendung, verteilt Nginx die Anfragen auf sie. Näheres: Lastverteilung.
   • Cache: Bewahrt eine Kopie der Antworten des Backends für eine bestimmte Zeit auf; kommt dieselbe Anfrage erneut, antwortet Nginx, ohne die Anwendung auszuführen. Näheres: Caching und Komprimierung.

   Verbreitet ist außerdem, die HTTPS-Verbindung an Nginx enden zu lassen und die Anfrage unverschlüsselt an die dahinterliegende Anwendung weiterzugeben (SSL-/TLS-Terminierung).

   : Vergrößern

2. 2

   Ereignisgesteuerte Architektur: wenige Prozesse, viele Verbindungen

   Läuft Nginx, sehen Sie zwei Arten von Prozessen. Der Master-Prozess liest die Konfiguration, startet die Worker-Prozesse und steuert das Neuladen. Die Worker-Prozesse bedienen die Verbindungen der Besucher.

   Entscheidend ist: Es wird nicht für jede Verbindung ein eigener Prozess oder Thread geöffnet. Jeder Worker-Prozess beobachtet sehr viele Verbindungen gleichzeitig und kümmert sich nur um diejenige, bei der gerade etwas zu tun ist (Daten sind eingetroffen oder können gesendet werden). Das nennt man ereignisgesteuerte (event-driven) Arbeitsweise. Die langsame Verbindung eines Besuchers hält den Worker nicht untätig fest; er bedient währenddessen andere Verbindungen.

   Die Zahl der Worker-Prozesse wird mit der Direktive worker_processes festgelegt; der Wert auto richtet sie nach der Zahl der Prozessorkerne. Diese Architektur soll den Speicherbedarf vor allem dann berechenbar halten, wenn sehr viele gleichzeitige Verbindungen offen bleiben. Die tatsächliche Leistung hängt jedoch von Ihrer Website, Ihrer Anwendung und der Konfiguration ab; ohne Messung zu verallgemeinern wäre nicht richtig.

   : Vergrößern

3. 3

   Der Unterschied zu Apache

   Auch Apache ist ein etablierter und weit verbreiteter Webserver. Beide erledigen dieselbe Aufgabe, verfolgen bei der Konfiguration aber unterschiedliche Ansätze.

   • Es gibt keine .htaccess. Apache liest, sofern erlaubt, die Datei .htaccess in jedem Ordner zum Zeitpunkt der Anfrage; ändern Sie die Datei, gilt die Einstellung sofort, und der Server muss nicht neu gestartet werden. Nginx kennt eine solche Datei nicht; eine in den Ordner gelegte .htaccess bewirkt nichts.
   • Die Konfiguration ist zentral. Bei Nginx liegen alle Einstellungen in den Konfigurationsdateien auf dem Server; um sie zu ändern, sind in der Regel Administratorrechte nötig.
   • Änderungen erfordern Test und Reload. Die Datei zu speichern genügt nicht; zuerst wird die Syntax geprüft, dann wird Nginx angewiesen, die Konfiguration neu einzulesen.
   • PHP führt Nginx nicht selbst aus. Apache kann PHP als Modul im eigenen Prozess ausführen. Nginx gibt die Anfrage an das getrennt laufende PHP-FPM weiter. Näheres: Nginx und PHP-FPM.

   Auch Apache besitzt einen ereignisbasierten Betriebsmodus und lässt sich mit PHP-FPM betreiben; der Unterschied ist also nicht schwarz-weiß. Die eigentliche Trennlinie ist, wo die Einstellungen liegen und wer sie ändern kann. Wie Sie vorhandene .htaccess-Regeln übertragen, zeigt die Anleitung zum Umstieg von Apache auf Nginx.

   : Vergrößern

4. 4

   Beide zusammen: Nginx vorn, Apache dahinter

   Sie müssen sich nicht zwischen Nginx und Apache entscheiden. Eine verbreitete Anordnung sieht so aus: Nginx empfängt den Besucher, liefert statische Dateien selbst aus und verwaltet die HTTPS-Verbindung; die übrigen Anfragen leitet es als Reverse Proxy an den dahinterliegenden Apache weiter. Apache führt weiterhin die Anwendung und die .htaccess-Regeln aus.

   Der Nutzen dieser Anordnung: Sie setzen eine Schicht davor, ohne die bestehende Anwendung zu ändern, die auf .htaccess angewiesen ist. Der Preis: Es sind zwei Programme zu verwalten, also zwei Konfigurationen, zwei Protokolle (Logs) und eine zusätzliche Einstellung, damit Apache die echte IP-Adresse des Besuchers sieht. Die Einrichtung beschreibt die Anleitung Reverse Proxy einrichten.

   : Vergrößern

5. 5

   Aufbau der Konfiguration: http, server, location

   Die Nginx-Konfiguration besteht aus ineinander verschachtelten Blöcken. Jede Zeile ist eine Direktive und endet mit einem Semikolon; Blöcke werden mit geschweiften Klammern geöffnet und geschlossen.

   • Der http-Block: Allgemeine Einstellungen für den Webverkehr. Sie gelten für alle Websites.
   • Der server-Block: Beschreibt eine einzelne Website (Domain); er entspricht dem virtuellen Host bei Apache. Hier steht, auf welchem Port gelauscht wird (listen) und für welche Domainnamen geantwortet wird (server_name).
   • Der location-Block: Legt fest, wie ein bestimmtes Adressmuster der Website behandelt wird (z. B. /, /img/, Adressen, die auf .php enden).

   Der innere Block erbt die Einstellungen des äußeren und ersetzt sie bei Bedarf durch einen eigenen Wert. In ihrer einfachsten Form sieht eine vollständige Konfigurationsdatei so aus:

   Nginx

   # Hauptkontext: der Prozess insgesamt
   worker_processes auto;
   
   events {
       worker_connections 1024;
   }
   
   http {
       # Gemeinsame Einstellungen für alle Websites
       include mime.types;
       default_type application/octet-stream;
   
       server {
           # Eine einzelne Website
           listen 80;
           server_name beispiel.de;
           root /var/www/beispiel.de/public;
   
           location / {
               # Regeln für ein bestimmtes Adressmuster
               try_files $uri $uri/ =404;
           }
       }
   }

   In der Praxis liegt jede Website in einer eigenen Datei, und die Hauptdatei bindet diese mit include ein. Die Hauptdatei liegt meist unter /etc/nginx/nginx.conf; der Ort der Website-Dateien hängt von der Distribution ab (/etc/nginx/conf.d/ ist verbreitet; /etc/nginx/sites-available/ und sites-enabled/ sind die Struktur von Debian und Ubuntu).

   Das folgende Beispiel ist ein kleiner server-Block, der eine statische Website ausliefert. Der Ordnerpfad ist ein Beispiel; tragen Sie den Pfad Ihres eigenen Servers ein.

   Nginx

   server {
       listen 80;
       listen [::]:80;
       server_name beispiel.de www.beispiel.de;
   
       # Ordner mit den Dateien der Website und Standarddokument
       root /var/www/beispiel.de/public;
       index index.html;
   
       # Erst die Datei, dann den Ordner suchen; sonst 404 zurückgeben
       location / {
           try_files $uri $uri/ =404;
       }
   
       # Statische Dateien dürfen 30 Tage im Browser gespeichert werden
       location ~* \.(css|js|png|jpg|jpeg|gif|svg|webp|woff2)$ {
           expires 30d;
       }
   
       # Versteckte Dateien mit führendem Punkt (.git, .env, .htaccess) werden nicht ausgeliefert;
       # ausgenommen /.well-known/, das für die Zertifikatsvalidierung genutzt wird
       location ~ /\.(?!well-known) {
           deny all;
       }
   }

   try_files sucht die angefragte Adresse zuerst als Datei, dann als Ordner; wird nichts gefunden, gibt Nginx 404 zurück. Dieses Beispiel lauscht nur auf HTTP (80); für HTTPS geht es weiter mit der Anleitung HTTPS und SSL-Zertifikat.

   : Vergrößern

6. 6

   Grundbefehle: erst testen, dann neu laden

   Nach jeder Änderung an der Konfiguration folgen zwei Schritte: zuerst die Prüfung, dann das Neuladen.

   Bash

   # 1. Konfiguration prüfen (zeigt bei einem Syntaxfehler Datei und Zeile)
   sudo nginx -t
   
   # 2. Unterbrechungsfrei neu laden (einer der beiden Befehle genügt)
   sudo systemctl reload nginx
   sudo nginx -s reload
   
   # Hilfreiche Befehle
   nginx -v                     # zeigt die installierte Version
   sudo nginx -T                # gibt die gesamte wirksame Konfiguration aus
   sudo systemctl status nginx  # läuft der Dienst?

   Findet nginx -t einen Fehler, nennt es Dateinamen und Zeilennummer; laden Sie nicht neu, solange der Fehler nicht behoben ist. Das Neuladen (Reload) unterbricht die Website nicht: Der Master-Prozess startet mit der neuen Konfiguration neue Worker-Prozesse, die alten Worker schließen ihre laufenden Anfragen ab und beenden sich. Ein Neustart (Restart) dagegen trennt Verbindungen; für gewöhnliche Konfigurationsänderungen ist er nicht nötig.

Wann welcher Webserver?

Auf die Frage „Welcher ist besser?“ gibt es keine einzige Antwort. Die Wahl sollten nicht Behauptungen über Geschwindigkeit bestimmen, sondern konkrete Kriterien wie die folgenden.

Wenn Sie unschlüssig sind, lautet die entscheidende Frage: Gibt es ein konkretes Problem, das die bestehende Umgebung nicht löst? Eine funktionierende Website nur in der Erwartung umzuziehen, dass sie „schneller wird“, kann mehr Risiko als Gewinn bringen. Messen Sie vor und nach der Änderung an Ihrer eigenen Website.

Häufige Fehler

• Erwarten, dass .htaccess funktioniert: Nach dem Umstieg auf Nginx werden Weiterleitungen, Zugriffsbeschränkungen und Regeln für „saubere Adressen“ stillschweigend unwirksam, wenn sie nicht in die Serverkonfiguration übertragen werden. Geschützte Ordner können offen liegen; prüfen Sie diese nach dem Umstieg einzeln.
• Neu laden, ohne zu testen: Zuerst nginx -t. Ein Neustart mit fehlerhafter Konfiguration kann die Website lahmlegen.
• Semikolon oder Klammer vergessen: Das sind die häufigsten Syntaxfehler; der Testbefehl zeigt die Zeile.
• Datei speichern und auf die Änderung warten: Solange nicht neu geladen wird, arbeitet Nginx mit der alten Konfiguration weiter.
• Die Live-Datei ohne Sicherung bearbeiten: Legen Sie vor der Änderung eine Kopie der Datei an; geht etwas schief, sind Sie in einer Minute zurück.

Wegweiser: die nächsten Anleitungen

Je nach Bedarf können Sie die Anleitungen dieser Kategorie in folgender Reihenfolge lesen:

• Grundbegriffe: Was ist ein Proxy-Server?, Was ist ein Reverse Proxy?, Was ist Lastverteilung?, Was ist ein CDN?
• Einrichtung und Konfiguration: Reverse Proxy mit Nginx einrichten, HTTPS und SSL-Zertifikat, Nginx und PHP-FPM.
• Leistung: Caching und Komprimierung.
• Sicherheit: Nginx-Sicherheitseinstellungen; ergänzend Sicherheitsheader und HTTPS.
• Fehlersuche: 502, 504 und weitere Nginx-Fehler.
• Umstieg: von Apache und .htaccess auf Nginx.

Häufige Fragen

Verwandte Anleitungen

• Was ist ein Reverse Proxy?Aufgaben eines Reverse Proxys, typische Architekturen, echte Besucher-IP und Header, Verhältnis zum CDN und ein kurzes Nginx-Beispiel.
• Nginx und PHP-FPM: So laufen PHP-Websites mit Nginxfastcgi_pass, SCRIPT_FILENAME, try_files, das Pool-Konzept, Socket-Berechtigungen und der Fehler 502.
• Umstieg von Apache und .htaccess auf NginxBeispiele im direkten Vergleich, eine Entsprechungstabelle und eine Testliste für die Übertragung von .htaccess-Regeln nach Nginx.
• HTTPS in Nginx: SSL-Zertifikat einrichtenZertifikat beziehen, auf HTTPS weiterleiten, HSTS, SSL-Terminierung und automatische Erneuerung in Nginx.