Nginx (ausgesprochen "Engine-X") ist der meistgenutzte Webserver der Welt - und das aus gutem Grund. Wenn du eine Website betreibst, die schnell laden soll, hohen Traffic bewältigen muss oder als Reverse Proxy vor deinen Anwendungsservern arbeiten soll, führt kaum ein Weg an Nginx vorbei.

Die Geschichte von Nginx beginnt 2004, als der russische Entwickler Igor Sysoev eine Lösung für das sogenannte C10K-Problem suchte. Die Herausforderung: Wie kann ein einzelner Server 10.000 gleichzeitige Verbindungen verarbeiten, ohne in die Knie zu gehen? Apache, damals der unangefochtene Standard, stieß bei solchen Lasten an seine Grenzen. Sysoevs Antwort war eine radikal neue Architektur - event-basiert, asynchron und extrem ressourceneffizient.

Heute, über 20 Jahre später, hat Nginx Apache als Marktführer abgelöst. Mit einem Marktanteil von 33-42% (je nach Quelle) bedient Nginx die größten Websites der Welt. Netflix, Dropbox, WordPress.com, Airbnb - sie alle setzen auf Nginx. Ob du einen kleinen persönlichen Blog betreibst oder die Infrastruktur eines Großkonzerns planst: Nginx skaliert mit deinen Anforderungen.

Technische Architektur: Warum Nginx so schnell ist

Um zu verstehen, warum Nginx performanter als viele Alternativen ist, musst du die fundamentale Architektur verstehen. Der Unterschied zu klassischen Webservern wie Apache ist grundlegend.

Event-driven und asynchron

Apache arbeitet traditionell mit einem Process- oder Thread-per-Connection-Modell. Jede eingehende Verbindung bekommt einen eigenen Prozess oder Thread zugewiesen. Das funktioniert bei moderaten Besucherzahlen gut, aber bei tausenden gleichzeitigen Verbindungen explodieren der Speicherverbrauch und die CPU-Last durch Context-Switching.

Nginx verfolgt einen anderen Ansatz: Das Event-driven-Modell. Anstatt für jede Verbindung einen eigenen Prozess zu erstellen, verarbeitet ein einzelner Worker-Prozess tausende Verbindungen gleichzeitig. Nginx wartet nicht blockierend auf langsame Operationen wie Festplatten-I/O oder Netzwerk-Antworten, sondern wechselt zur nächsten Aufgabe und kommt später zurück.

Das Master-Worker-Modell

Nginx verwendet eine elegante Prozessarchitektur:

Master-Prozess: Läuft als root, liest die Konfiguration, bindet Ports und startet Worker-Prozesse
Worker-Prozesse: Verarbeiten die eigentlichen Anfragen, laufen mit reduzierten Rechten

Du kannst die Anzahl der Worker-Prozesse konfigurieren - typischerweise entspricht sie der Anzahl der CPU-Kerne. Jeder Worker kann zehntausende Verbindungen gleichzeitig handhaben.

# In nginx.conf
worker_processes auto;  # Automatisch basierend auf CPU-Kernen
worker_connections 10240;  # Max. Verbindungen pro Worker

Protokoll-Support

Nginx unterstützt alle modernen Protokolle:

HTTP/1.1: Der klassische Standard
HTTP/2: Multiplexing, Server Push, Header-Kompression
HTTP/3: QUIC-basiert, seit Nginx 1.25.0 experimentell, ab 1.27.0 stabil
gRPC: Für moderne Microservice-Kommunikation
WebSocket: Für bidirektionale Echtzeitkommunikation

Plattform-Unterstützung

Nginx läuft auf allen gängigen Plattformen:

Linux: Volle Unterstützung, empfohlen für Produktion
FreeBSD: Exzellente Performance, beliebte Server-Plattform
macOS: Perfekt für lokale Entwicklung
Windows: Funktioniert, aber mit Einschränkungen (kein Worker-Prozess-Modell, reduzierte Performance)

Für produktive Deployments empfehle ich Linux - hier läuft Nginx am besten optimiert.

Nginx installieren: Schritt für Schritt

Die Installation von Nginx ist auf allen großen Linux-Distributionen unkompliziert. Hier die Anleitungen für die gängigsten Systeme.

Debian / Ubuntu

Auf Debian-basierten Systemen ist die Installation ein Einzeiler:

sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
sudo systemctl start nginx

Nach der Installation läuft Nginx automatisch und ist unter http://localhost erreichbar. Du siehst die Standard-Willkommensseite.

CentOS / RHEL / Fedora

Auf Red Hat-basierten Systemen:

sudo dnf install nginx
sudo systemctl enable nginx
sudo systemctl start nginx

Falls du eine ältere CentOS-Version mit yum verwendest, ersetze dnf durch yum.

Docker

Für containerisierte Umgebungen:

docker run -d -p 80:80 --name nginx nginx:latest

Für Produktion solltest du deine eigene Konfiguration mounten:

docker run -d \
  -p 80:80 \
  -p 443:443 \
  -v /pfad/zu/nginx.conf:/etc/nginx/nginx.conf:ro \
  -v /pfad/zu/html:/usr/share/nginx/html:ro \
  --name nginx nginx:latest

Wichtige Verzeichnisse und Dateien

Nach der Installation findest du die wichtigsten Dateien hier:

Pfad	Beschreibung
`/etc/nginx/nginx.conf`	Haupt-Konfigurationsdatei
`/etc/nginx/sites-available/`	Verfügbare Virtual Hosts (Debian/Ubuntu)
`/etc/nginx/sites-enabled/`	Aktivierte Virtual Hosts (Symlinks)
`/etc/nginx/conf.d/`	Zusätzliche Konfigurationsdateien
`/var/log/nginx/`	Access- und Error-Logs
`/var/www/html/`	Standard Document Root

Grundlegende Konfiguration verstehen

Die Nginx-Konfiguration folgt einer hierarchischen Struktur. Hier ein minimales Beispiel:

# /etc/nginx/sites-available/meine-website
server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;
    root /var/www/meine-website;
    index index.html index.htm;

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

    location /images/ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

Was bedeutet das?

listen 80: Lausche auf Port 80 (HTTP)
server_name: Für welche Domains gilt diese Konfiguration
root: Wo liegen die Dateien
index: Welche Datei wird bei Verzeichnisaufruf geladen
location /: Wie werden Anfragen zum Root verarbeitet
try_files: Versuche Datei, dann Verzeichnis, sonst 404

Um eine neue Site zu aktivieren (Debian/Ubuntu):

sudo ln -s /etc/nginx/sites-available/meine-website /etc/nginx/sites-enabled/
sudo nginx -t  # Konfiguration testen
sudo systemctl reload nginx

Performance: Benchmarks und Optimierung

Nginx ist bekannt für seine herausragende Performance. Aber wie gut ist er wirklich, und wo liegen seine Stärken?

Benchmark-Zahlen

In typischen Benchmarks erreicht Nginx beeindruckende Werte:

Statische Dateien: 100.000+ Requests pro Sekunde (bei kleinen Dateien)
Reverse Proxy: 50.000-80.000 Requests pro Sekunde
SSL/TLS: 20.000-40.000 HTTPS-Requests pro Sekunde

Der Memory-Footprint ist dabei minimal: Ein Worker-Prozess benötigt etwa 2-3 MB RAM. Selbst mit 8 Workern und 10.000 aktiven Verbindungen bleibt der Speicherverbrauch unter 100 MB.

Nginx vs. Apache: Der Vergleich

Metrik	Nginx	Apache (Event MPM)
Statische Files	Sehr schnell	Schnell
Speicherverbrauch	~2-3 MB/Worker	~10-20 MB/Prozess
Concurrent Connections	10.000+ pro Worker	Hunderte pro Prozess
Konfigurationsänderung	Reload ohne Downtime	Graceful Restart
.htaccess Support	Nein	Ja

Bei statischen Inhalten ist Nginx typischerweise 2-3x schneller als Apache. Der Unterschied verkleinert sich bei dynamischen Inhalten, da hier PHP-FPM oder der Application Server der Bottleneck ist.

Wann Nginx glänzt

Nginx ist die beste Wahl wenn du:

Viele statische Dateien auslieferst (Bilder, CSS, JavaScript)
Einen Reverse Proxy vor Node.js, Python oder Go brauchst
High-Concurrency erwartest (viele gleichzeitige Verbindungen)
Load Balancing zwischen mehreren Backend-Servern benötigst
Ressourcen sparen willst (wenig RAM, wenig CPU)

Wann Nginx weniger geeignet ist

Nginx ist nicht ideal wenn:

Du auf .htaccess-Dateien angewiesen bist (WordPress-Plugins, Shared Hosting)
Du mod_php direkt im Webserver brauchst (legacy PHP-Setups)
Die Konfiguration von Nicht-Admins geändert werden soll
Du sehr komplexe Rewrite-Regeln hast, die von .htaccess migriert werden müssen

Typische Einsatzszenarien mit Konfigurationsbeispielen

Nginx ist vielseitig einsetzbar. Hier sind die häufigsten Szenarien mit produktionsreifen Konfigurationen.

Reverse Proxy vor Node.js/Python/Go

Das häufigste Setup: Nginx als Frontend, das SSL terminiert und Anfragen an einen Application Server weiterleitet.

upstream nodejs_backend {
    server 127.0.0.1:3000;
    keepalive 64;
}

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name api.example.com;

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;

    location / {
        proxy_pass http://nodejs_backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Die Upgrade-Header sind wichtig für WebSocket-Verbindungen. keepalive 64 hält 64 Verbindungen zum Backend offen, was die Latenz bei vielen Anfragen reduziert.

WordPress mit PHP-FPM

WordPress läuft optimal mit Nginx und PHP-FPM. Hier eine bewährte Konfiguration:

server {
    listen 80;
    server_name wordpress.example.com;
    root /var/www/wordpress;
    index index.php;

    # Statische Dateien cachen
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # WordPress Permalinks
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # Sicherheit: Keine direkten Zugriffe auf versteckte Dateien
    location ~ /\. {
        deny all;
    }

    # wp-config.php schützen
    location = /wp-config.php {
        deny all;
    }
}

Load Balancing

Nginx kann Traffic auf mehrere Backend-Server verteilen:

upstream backend_cluster {
    least_conn;  # Verbindungen zum Server mit wenigsten aktiven Verbindungen

    server 10.0.0.1:8080 weight=3;  # 3x mehr Traffic
    server 10.0.0.2:8080 weight=2;
    server 10.0.0.3:8080;
    server 10.0.0.4:8080 backup;    # Nur bei Ausfall der anderen

    keepalive 32;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://backend_cluster;
        proxy_next_upstream error timeout http_502 http_503;
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }

    # Health Check Endpoint
    location /health {
        access_log off;
        return 200 "OK";
        add_header Content-Type text/plain;
    }
}

Verfügbare Load-Balancing-Methoden:

round-robin (Standard): Gleichmäßige Verteilung
least_conn: Server mit wenigsten aktiven Verbindungen
ip_hash: Gleiche IP immer zum gleichen Server (Session-Sticky)
hash: Benutzerdefinierter Hash-Key

SSL/TLS Termination mit Let's Encrypt

Mit Certbot ist die SSL-Konfiguration ein Kinderspiel:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot modifiziert automatisch deine Nginx-Konfiguration und richtet einen Cronjob für die automatische Erneuerung ein. Für eine optimale SSL-Konfiguration (SSL Labs A+):

# SSL-Optimierung in /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;

Sicherheit: Nginx richtig absichern

Ein falsch konfigurierter Webserver ist ein Einfallstor für Angriffe. Hier die wichtigsten Sicherheitsmaßnahmen.

Security Headers

Schütze deine Besucher mit den richtigen HTTP-Headern:

# In server {} Block oder http {} für global
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

# Content Security Policy (anpassen an deine Bedürfnisse!)
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

Rate Limiting

Schütze dich vor Brute-Force und DDoS-Angriffen:

# In http {} Block
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

# In server {} oder location {}
location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    # ...
}

location /wp-login.php {
    limit_req zone=login_limit burst=3;
    # ...
}

Das erlaubt 10 Requests pro Sekunde zur API (mit Burst bis 20) und nur 1 Request pro Sekunde zum Login.

Server-Härtung

Verstecke unnötige Informationen und reduziere die Angriffsfläche:

# In http {} Block
server_tokens off;  # Nginx-Version verstecken

# Nur erlaubte HTTP-Methoden
if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE|OPTIONS)$) {
    return 405;
}

# Buffer-Overflow-Schutz
client_body_buffer_size 1K;
client_header_buffer_size 1k;
client_max_body_size 10M;
large_client_header_buffers 2 1k;

Fail2ban Integration

Kombiniere Nginx-Logs mit Fail2ban für automatische IP-Sperren:

# /etc/fail2ban/filter.d/nginx-req-limit.conf
[Definition]
failregex = limiting requests, excess:.* by zone.*client: <HOST>

Vor- und Nachteile von Nginx

Vorteile

Extrem performant bei statischen Inhalten Nginx ist unschlagbar beim Ausliefern von Bildern, CSS, JavaScript und anderen statischen Dateien. Die Event-basierte Architektur ermöglicht zehntausende gleichzeitiger Verbindungen.

Niedriger Speicherverbrauch Mit nur 2-3 MB pro Worker-Prozess ist Nginx ideal für ressourcenbeschränkte Umgebungen. Ein kompletter Nginx-Stack verbraucht oft weniger RAM als ein einzelner Apache-Prozess.

Exzellent als Reverse Proxy Die Reverse-Proxy-Funktionalität ist erstklassig. Load Balancing, Health Checks, WebSocket-Support - alles eingebaut und performant.

Aktive Community und regelmäßige Updates Nginx wird aktiv weiterentwickelt. Security-Patches erscheinen zeitnah, und neue Features wie HTTP/3 werden kontinuierlich hinzugefügt.

HTTP/3-Support Seit Version 1.25.0 unterstützt Nginx HTTP/3 mit QUIC. Ab Version 1.27.0 ist der Support stabil und produktionsreif.

Nachteile

Keine .htaccess-Unterstützung Alle Konfigurationen müssen zentral in den Nginx-Konfigurationsdateien erfolgen. Für Shared-Hosting-Umgebungen, in denen Kunden eigene Rewrite-Regeln brauchen, ist das problematisch.

Steilere Lernkurve als Apache Die Nginx-Konfigurationssyntax ist anders als Apache. Wer von Apache kommt, muss umlernen. Die Dokumentation ist gut, aber nicht so umfangreich wie bei Apache.

Kein natives PHP-Modul Nginx kann PHP nicht direkt verarbeiten. Du brauchst zusätzlich PHP-FPM als separaten Prozess. Das ist effizienter, aber komplexer einzurichten.

Dynamische Inhalte langsamer als spezialisierte Server Bei rein dynamischen Anwendungen ohne statische Assets verliert Nginx seinen Vorteil. Für eine reine API könnte ein spezialisierter Application Server besser geeignet sein.

Fazit: Wann Nginx die richtige Wahl ist

Nginx hat sich seinen Platz als Marktführer verdient. Die Kombination aus Performance, Effizienz und Vielseitigkeit macht ihn zur ersten Wahl für die meisten Webprojekte.

Nginx ist ideal für dich, wenn:

Du hohe Performance bei statischen Inhalten brauchst
Du einen Reverse Proxy vor Node.js, Python, Go oder Java benötigst
Du Load Balancing zwischen mehreren Servern einrichten willst
Ressourceneffizienz wichtig ist (Cloud, VPS, Container)
Du moderne Protokolle wie HTTP/3 nutzen möchtest

Nginx ist weniger geeignet, wenn:

Du zwingend .htaccess-Support brauchst
Du in einer Shared-Hosting-Umgebung ohne Root-Zugriff arbeitest
Dein Team nur Apache-Erfahrung hat und keine Zeit zum Umlernen

Für die meisten modernen Webprojekte ist Nginx die sichere Wahl. Die Lernkurve mag anfangs steiler sein als bei Apache, aber die Performance-Gewinne und die elegante Konfiguration machen das schnell wett.

Zurück zum Webserver-Vergleich 2026

Weiterführende Ressourcen

Hier findest du weitere Informationen zu Nginx und verwandten Themen:

Offizielle Nginx-Dokumentation - Die umfassende Referenz direkt von Nginx
Apache HTTP Server 2026 - Der klassische Konkurrent im Detail
LiteSpeed Webserver 2026 - Die performante Alternative für PHP

Letzte Aktualisierung: März 2026

Nginx Webserver 2026: Installation, Konfiguration & Performance