Vergleich von Apache- und Nginx-Webservern

Zwei Server, zwei Designphilosophien

Apache HTTP Server und Nginx sind die beiden Open-Source-Webserver, denen Sie auf Hosting-Konten, VPS und Cloud-Images am wahrscheinlichsten begegnen. Beide sind ausgereift, werden aktiv gepflegt, sind bei richtiger Konfiguration sicher und können sehr stark besuchte Websites ausliefern. Die Unterschiede liegen darin, wie sie Verbindungen verarbeiten, wie sie konfiguriert werden und welche Aufgaben sie leicht machen.

Apache erschien Mitte der 1990er-Jahre und wurde zum Standard-Webserver des frühen Internets. Nginx entstand Anfang der 2000er-Jahre gezielt, um sehr viele gleichzeitige Verbindungen effizient zu bewältigen – eine Herausforderung, die oft als C10k-Problem bezeichnet wird. Diese Herkunft prägt das Verhalten beider Server bis heute.

Architektur: Prozesse, Threads und Events

Apache und seine Multi-Processing-Module

Apache überlässt die Verbindungsverarbeitung einem Multi-Processing-Modul (MPM):

• prefork startet einen Prozess pro Verbindung, ohne Threads. Es ist sehr kompatibel, auch mit nicht threadsicheren Modulen wie dem alten mod_php, verbraucht aber den meisten Speicher.
• worker betreibt mehrere Threads pro Prozess und benötigt weniger Speicher pro Verbindung.
• event ähnelt worker, übergibt aber ruhende Keep-Alive-Verbindungen an einen Listener-Thread und entlastet so die Worker-Threads. Auf vielen aktuellen Distributionen ist es der Standard.

Nginx und seine Event-Schleife

Nginx startet einen Master-Prozess und eine kleine Zahl von Worker-Prozessen, meist einen pro CPU-Kern. Jeder Worker führt eine nicht blockierende Event-Schleife aus und kann Tausende Verbindungen gleichzeitig jonglieren, ohne für jede einen Thread zu erzeugen. Der Speicherverbrauch bleibt bei steigender Parallelität relativ konstant. Deshalb wurde Nginx für Websites mit viel Traffic, für Reverse Proxys und Load Balancer populär.

Direkter Vergleich

Statische und dynamische Inhalte

Für statische Dateien wie Bilder, Stylesheets und Skripte ist Nginx in der Regel die ressourcenschonendere Wahl, und sein Vorsprung wächst tendenziell mit der Zahl gleichzeitiger Verbindungen. Apache mit dem event-MPM verringert den Abstand im Vergleich zu älteren prefork-Setups deutlich, sodass der Unterschied bei einer kleineren Website gering sein kann.

Bei dynamischen Inhalten ist das Bild ausgeglichener. In modernen Installationen übergeben beide Server PHP-Anfragen meist per FastCGI an PHP-FPM. Ab diesem Punkt ist der Webserver vor allem ein Verkehrsverteiler, und die Antwortzeit hängt größtenteils von PHP-Version, OPcache, Objekt-Caching, Datenbankabfragen und Anwendungscode ab. Ein Wechsel des Webservers behebt selten ein langsames WordPress-Plugin oder eine Datenbanktabelle ohne Index.

Konfiguration: .htaccess oder zentrale Konfiguration

Der Unterschied, den die meisten Websitebetreiber zuerst bemerken, ist die Konfiguration. Apache kann .htaccess-Dateien in jedem Verzeichnis lesen. So können Nutzer im Shared Hosting Weiterleitungen, Rewrite-Regeln und Zugriffskontrollen hinzufügen, ohne die Hauptkonfiguration des Servers anzufassen. Das ist bequem, doch Apache muss bei jeder Anfrage entlang des Verzeichnispfads nach diesen Dateien suchen, was etwas Overhead verursacht, und verstreute Regeln sind schwer zu überprüfen.

Nginx hat keine Entsprechung. Alle Regeln stehen in der Serverkonfiguration. Das ist schneller und leichter nachvollziehbar, erfordert aber Zugriff auf diese Konfiguration und ein Neuladen nach Änderungen.

Beispiel: HTTP auf HTTPS umleiten

Apache, in einem Virtual Host oder in der .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx, im server-Block:

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

Beispiel: sprechende Permalinks für eine PHP-Anwendung

Nginx mit PHP-FPM:

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~ [.]php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Der Socket-Pfad unterscheidet sich je nach Distribution und PHP-Version. Prüfen Sie Ihren, bevor Sie das Beispiel übernehmen.

Module, Ökosystem und Kompatibilität

Das Modulsystem gehört zu den Stärken von Apache. Module wie mod_rewrite, mod_security, mod_headers und zahlreiche Authentifizierungsmodule lassen sich per Befehl aktivieren und ohne Neukompilierung laden. Viele Hosting-Control-Panels, darunter cPanel, sind auf Apache oder Apache-kompatible Server ausgelegt, und unzählige Anwendungen liefern .htaccess-Regeln aus, die Apache voraussetzen.

Bei Nginx mussten Module früher einkompiliert werden, doch dynamische Module werden seit Jahren unterstützt, und Distributionspakete enthalten die gängigen. Sein Ökosystem ist rund um Proxying, Caching, Rate Limiting und TLS-Terminierung am stärksten. Viele Anwendungen veröffentlichen inzwischen offizielle Nginx-Konfigurationsschnipsel neben ihren Apache-Regeln.

Wenn Sie cPanel-Server betreiben, behandelt unser Leitfaden mit Tipps zur Automatisierung von cPanel-Hosting verwandte Wartungsaufgaben.

Nginx und Apache gemeinsam nutzen

Sie müssen sich nicht für nur einen entscheiden. Ein weit verbreitetes Muster stellt Nginx als Reverse Proxy davor:

• Nginx nimmt alle Client-Verbindungen an, terminiert TLS und liefert statische Dateien direkt aus.
• Er kann Antworten cachen und Rate Limits anwenden.
• Anfragen nach dynamischen Seiten werden an Apache auf einem lokalen Port weitergeleitet, wo bestehende .htaccess-Regeln weiter funktionieren.

location / {
    proxy_pass http://127.0.0.1:8080;
    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;
}

Achten Sie darauf, dass das Backend die weitergeleitete Client-IP protokolliert und ihr vertraut (etwa mit mod_remoteip in Apache), sonst scheint jeder Besucher von 127.0.0.1 zu kommen. Der Preis ist eine zusätzliche Ebene, die konfiguriert, überwacht und aktualisiert werden muss.

Tuning, Sicherheit und Wartung

Tuning-Tipps, die mehr zählen als die Wahl des Servers

Egal welchen Server Sie betreiben: Eine Handvoll Einstellungen wirkt sich auf die reale Geschwindigkeit meist stärker aus als ein Softwarewechsel:

• Aktivieren Sie HTTP/2 (und HTTP/3, wo Ihre Version und Ihr Setup es unterstützen), damit Browser viele Dateien über eine Verbindung laden können.
• Komprimieren Sie Textantworten mit gzip oder Brotli. Apache nutzt dafür mod_deflate oder mod_brotli, Nginx die gzip-Direktiven und, sofern installiert, ein Brotli-Modul.
• Setzen Sie Cache-Header für statische Dateien, damit wiederkehrende Besucher und CDNs sie nicht unnötig erneut anfordern.
• Dimensionieren Sie PHP-FPM richtig. Zu wenige Worker stauen Anfragen, zu viele erschöpfen den Speicher. Orientieren Sie das Limit am verfügbaren RAM und am durchschnittlichen Speicher pro Prozess.
• Halten Sie Keep-Alive vernünftig. Sehr lange Timeouts binden Ressourcen, besonders bei Apache mit prefork.
• Nutzen Sie das richtige Apache-MPM. Wenn Sie noch prefork mit mod_php einsetzen, ist der Wechsel zu event plus PHP-FPM oft die größte einzelne Verbesserung für Apache.

Die Komprimierung in Nginx zu aktivieren, braucht zum Beispiel nur wenige Zeilen:

gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1024;

Messen Sie vor und nach jeder Änderung. Werkzeuge, die Time to First Byte und Gesamtladezeit von mehreren Standorten aus messen, zeigen, ob eine Anpassung tatsächlich geholfen hat.

Sicherheitsgrundlagen für beide Server

Keiner der beiden Server ist von Natur aus unsicher, und beide Projekte veröffentlichen regelmäßig Sicherheitshinweise und Korrekturen. Die meisten Probleme in der Praxis entstehen durch veraltete Pakete, offen erreichbare Adminpfade, schwache TLS-Einstellungen oder zu großzügige Dateirechte. Bewährte Praxis für beide:

• Installieren Sie aus Ihrer Distribution oder den offiziellen Repositories und spielen Sie Sicherheitsupdates zeitnah ein.
• Verbergen Sie Versionsdetails (ServerTokens Prod in Apache, server_tokens off; in Nginx).
• Nutzen Sie moderne TLS-Einstellungen und automatisieren Sie die Zertifikatsverlängerung.
• Testen Sie die Konfiguration vor dem Neuladen: apachectl configtest bzw. nginx -t.
• Überwachen Sie Zugriffs- und Fehlerlogs auf ungewöhnlichen Traffic, wiederholt fehlgeschlagene Anfragen und Scan-Muster.

Auch eine automatische Verlängerung kann unbemerkt scheitern, etwa nach einer DNS-Änderung. Wenn Sie Ablaufdaten von Zertifikaten und Hosting im Hosting-Panel von TLDix erfassen, erhalten Sie eine Warnung, bevor Besucher eine Browserwarnung sehen.

Welchen sollten Sie wählen?

Wählen Sie Apache, wenn Sie auf .htaccess angewiesen sind, Shared Hosting oder ein darauf ausgelegtes Control Panel nutzen oder Anwendungen betreiben, die Apache-Module voraussetzen. Wählen Sie Nginx, wenn Sie Ihren eigenen VPS oder Cloud-Server verwalten, viele statische Inhalte oder gleichzeitige Verbindungen ausliefern oder einen Reverse Proxy, Load Balancer oder Cache benötigen. Wählen Sie beide, wenn Sie die Effizienz von Nginx im Frontend wollen und gleichzeitig die Apache-Kompatibilität einer bestehenden Anwendung behalten möchten.

Eine kurze Entscheidungshilfe

• Kein Root-Zugriff, Shared Hosting: Sie nutzen, was der Hoster bereitstellt – meist Apache oder einen kompatiblen Server.
• Eigener VPS, neue Anwendung: Nginx mit PHP-FPM ist ein schlanker, gut dokumentierter Startpunkt.
• Bestehende Anwendung mit vielen .htaccess-Regeln: Behalten Sie Apache und stellen Sie bei Bedarf Nginx davor.

Möchten Sie wissen, was eine bestimmte Website einsetzt? Die Antwort-Header verraten oft die Serversoftware, und die Hosting-Abfrage von TLDix zeigt den Anbieter hinter einer Domain. Hinweise zum Hosting selbst finden Sie unter Was VPS-Hosting ist und wer es braucht.