// <a href="https://hosting-fixers.de/category/pagespeed/" rel="category tag">Pagespeed</a>
Apache vs. Nginx für WordPress: Vor- und Nachteile, Konfiguration und Empfehlung
Apache und Nginx sind die zwei meistgenutzten Webserver für WordPress-Installationen weltweit. Apache arbeitet mit einem prozess- oder threadbasierten Modell und ist seit 1995 der meistverbreitete Webserver im Internet. Nginx wurde 2004 für hohe Parallelverbindungen entwickelt und nutzt eine ereignisgesteuerte, nicht-blockierende Architektur. Für WordPress macht die Wahl zwischen beiden einen messbaren Unterschied bei TTFB, statischer Dateiauslieferung und Verhalten unter Last.
TL;DR – Die wichtigsten Punkte
- Nginx ist für WordPress-Produktivumgebungen in den meisten Fällen die bessere Wahl: geringerer RAM-Verbrauch, schnellere statische Dateiauslieferung, besseres Verhalten unter Last
- Apache ist auf Shared Hosting unumgänglich (cPanel nutzt Apache standardmäßig) und bietet überlegene .htaccess-Unterstützung
- Das Nginx-Reverse-Proxy-Modell vor Apache kombiniert die Vorteile beider Server
- Nginx FastCGI-Cache ist die schnellste Page-Cache-Lösung für WordPress ohne zusätzliches Plugin
- Apache mod_rewrite ist für WordPress-Permalinks on Shared Hosting einfacher zu konfigurieren
- Nginx hat keinen nativen .htaccess-Support – alle Regeln müssen in der Server-Konfiguration stehen
Architektur: Wie Apache und Nginx Anfragen verarbeiten
Der grundlegende Unterschied zwischen Apache und Nginx liegt in der Verbindungsverarbeitung. Apache nutzt das Prefork- oder Worker-MPM-Modell: Für jede Verbindung wird ein eigener Prozess oder Thread erzeugt. Bei 500 gleichzeitigen Besuchern laufen 500 Apache-Prozesse oder Threads – jeder belegt RAM, auch wenn er gerade auf Datenbankabfragen oder PHP-Ausführung wartet.
Nginx nutzt dagegen ein ereignisgesteuertes, asynchrones Modell: Ein einzelner Worker-Prozess kann Tausende gleichzeitiger Verbindungen verwalten, ohne für jede Verbindung einen eigenen Thread zu benötigen. Wartende Verbindungen blockieren den Worker nicht – was bedeutet, dass Nginx auch bei 10.000 gleichzeitigen Verbindungen stabil bleibt, wo Apache längst an seine Prozess-Limits stoßen würde. Als Folge verbraucht Nginx bei hoher Last dramatisch weniger RAM als Apache.
Apache vs. Nginx: Der direkte Vergleich
| Eigenschaft | Apache | Nginx |
|---|---|---|
| Architektur | Prozess-/Thread-basiert (MPM) | Ereignisgesteuert, asynchron |
| RAM-Verbrauch unter Last | Hoch (1 Thread pro Verbindung) | Gering (1 Worker, n Verbindungen) |
| Statische Dateien | Gut | Sehr schnell – direktes Sendfile |
| PHP-Ausführung | mod_php (inline) oder PHP-FPM | Nur über PHP-FPM (FastCGI) |
| .htaccess-Support | Ja – per Verzeichnis konfigurierbar | Nein – nur Server-Konfiguration |
| WordPress Permalinks | Automatisch über .htaccess/mod_rewrite | try_files in server-Block erforderlich |
| Page-Cache | Über mod_cache oder Plugins | FastCGI-Cache nativ, sehr schnell |
| SSL/TLS-Termination | mod_ssl | Sehr effizient, OCSP-Stapling einfach |
| Reverse Proxy | mod_proxy (aufwändiger) | Nativ, hochperformant |
| Shared Hosting | Standard (cPanel, Plesk) | Selten direkt, meist als Reverse Proxy |
Apache – Vorteile für WordPress
- .htaccess-Support: WordPress schreibt Permalink-Regeln automatisch in die .htaccess. Auf Apache funktionieren Permalink-Änderungen ohne Server-Neustart und ohne Root-Zugriff. Auf Shared Hosting ist das entscheidend.
- mod_php: PHP läuft direkt im Apache-Prozess – kein separater PHP-FPM-Dienst nötig. Auf einfachen Setups reduziert das die Komplexität.
- Breite Hosting-Unterstützung: Nahezu jeder Shared-Hosting-Anbieter und jedes cPanel-Setup nutzt Apache. WordPress-spezifische Anleitungen beziehen sich häufig auf Apache-Konfiguration.
- Per-Verzeichnis-Konfiguration: .htaccess ermöglicht Konfiguration ohne Zugriff auf die Server-Hauptkonfiguration – ideal für Reseller-Hosting.
Apache – Nachteile für WordPress
- Hoher RAM-Verbrauch unter Last: Jede Verbindung benötigt einen eigenen Thread oder Prozess. Bei Traffic-Spitzen steigt der RAM-Bedarf linear – auf kleinen VPS kann das zu Out-of-Memory-Situationen führen.
- .htaccess-Overhead: Apache liest bei jedem Request alle .htaccess-Dateien im Pfad. Das ist bei tief verschachtelten Verzeichnisstrukturen messbar langsamer.
- Langsamere statische Dateiauslieferung: CSS, JS und Bilder werden über denselben Prozess ausgeliefert wie PHP-Requests. Nginx ist hier 2–5x schneller.
- Kein nativer FastCGI-Cache: Page-Caching auf Apache-Ebene erfordert zusätzliche Module oder Plugins. Nginx FastCGI-Cache ist einfacher und schneller.
Nginx – Vorteile für WordPress
- Geringer RAM-Verbrauch unter Last: Nginx-Worker verwalten Tausende Verbindungen ohne proportionalen RAM-Anstieg. Auf einem VPS mit 2 GB RAM kann Nginx problemlos 10.000 gleichzeitige Verbindungen halten, wo Apache bei 500 an die Grenzen stößt.
- FastCGI-Cache: Nginx kann fertig gerendertes HTML direkt cachen – ohne Plugin, ohne PHP-Aufruf. Bei Cache-HIT antwortet der Server in unter 5 ms.
- Schnelle statische Dateiauslieferung: CSS, JS, Bilder und Fonts werden über Nginx’ nativen sendfile()-Syscall direkt aus dem Dateisystem geliefert – ohne PHP, ohne Apache-Overhead.
- Effiziente SSL/TLS-Termination: OCSP-Stapling, Session-Tickets und HTTP/2 sind in Nginx einfach zu konfigurieren und haben wenig Overhead.
Nginx – Nachteile für WordPress
- Kein .htaccess-Support: Alle Konfigurationen müssen in der Nginx-Server-Konfiguration stehen. WordPress-Plugins, die .htaccess schreiben (z. B. für Sicherheitsregeln), funktionieren auf Nginx nicht automatisch.
- Root-Zugriff erforderlich: Konfigurationsänderungen erfordern Zugriff auf /etc/nginx/ und einen Reload des Dienstes. Auf Shared Hosting nicht möglich.
- Komplexere WordPress-Permalink-Konfiguration: try_files muss manuell in den Server-Block eingefügt werden. Bei Fehlkonfiguration liefert WordPress 404-Fehler für alle Unterseiten.
Nginx für WordPress konfigurieren
Der entscheidende Block für WordPress-Permalinks: location / mit try_files $uri $uri/ /index.php?$args – ohne diese Zeile funktionieren keine Unterseiten. PHP-Requests an PHP-FPM übergeben via fastcgi_pass auf den PHP-FPM-Socket (typisch: unix:/run/php/php8.3-fpm.sock). Statische Dateien direkt ausliefern: location ~* .(css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2)$ mit expires 1y und access_log off.
Nginx FastCGI-Cache für WordPress
Der FastCGI-Cache ist Nginx’ größter Vorteil gegenüber Apache für WordPress – weil er gecachtes HTML vor dem PHP-FPM-Prozess ausliefert und daher WordPress gar nicht erst startet. Konfiguration im nginx.conf (http-Block): fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=wordpress:100m inactive=60m max_size=1g. Cache-Bypass für eingeloggte User: fastcgi_cache_bypass $cookie_wordpress_logged_in. Bei korrekt konfiguriertem FastCGI-Cache antwortet WordPress auf gecachte Seiten mit TTFB unter 10 ms.
Apache für WordPress konfigurieren
Apache benötigt für WordPress die Module mod_rewrite, mod_headers und mod_expires. Die WordPress .htaccess-Datei erledigt Permalink-Rewriting automatisch – jedoch nur, sofern AllowOverride All im VirtualHost-Block gesetzt ist. Auf Shared Hosting ist das meistens der Fall, auf selbst konfigurierten VPS-Servern muss es dagegen explizit aktiviert werden.
Das beste Setup: Nginx als Reverse Proxy vor Apache
Auf cPanel-Servern (EA-Nginx) und vielen Managed-Hosting-Umgebungen läuft Nginx als Reverse Proxy vor Apache. Nginx übernimmt die statische Dateiauslieferung und den SSL-Abschluss, Apache verarbeitet PHP-Requests und ermöglicht weiterhin .htaccess. Dieses Setup kombiniert die Vorteile beider Server:
- Nginx liefert CSS, JS, Bilder direkt aus – Apache bekommt diese Requests nie zu sehen
- Apache verarbeitet PHP-Requests mit mod_php oder PHP-FPM
- .htaccess funktioniert weiterhin für Plugins und WordPress-Permalinks
- Nginx FastCGI-Cache kann zusätzlich vor Apache geschaltet werden
Wann Apache, wann Nginx?
| Szenario | Empfehlung | Begründung |
|---|---|---|
| Shared Hosting (cPanel, Plesk) | Apache | Standard, .htaccess funktioniert, kein Root nötig |
| VPS oder Root-Server, wenig Traffic | Nginx | Einfacher zu konfigurieren, geringerer RAM-Verbrauch |
| VPS oder Root-Server, hoher Traffic | Nginx | FastCGI-Cache, event-driven Architektur unter Last unschlagbar |
| WooCommerce-Shop mit hohem Traffic | Nginx + FastCGI-Cache | Cache-Bypass für Cart/Checkout, statische Assets blitzschnell |
| cPanel-Server mit EA-Nginx | Nginx vor Apache | Beste Kombination: Nginx für Statik, Apache für .htaccess und PHP |
Praxisbeispiel: Nginx FastCGI-Cache auf einem cPanel-Server
Auf einem AlmaLinux-8-Server mit cPanel und EA-Nginx wurde der Nginx FastCGI-Cache für die Hauptdomain aktiviert. Ausgangssituation: TTFB 820 ms bei ungeachtetem Apache-Stack. Nach Aktivierung des FastCGI-Cache mit korrekten Bypass-Regeln für wp-admin, wp-login.php und den Session-Cookie: TTFB auf gecachten Seiten 8 ms. Cache-HIT-Rate nach 24 Stunden: 97,4 %. Serverlast (Load Average) sank von durchschnittlich 2,8 auf 0,4 – obwohl der Traffic identisch blieb.
Weitere Fragen und Antworten
Was ist Nginx und wie unterscheidet es sich von Apache?
Nginx ist ein Webserver und Reverse Proxy, der 2004 als Alternative zu Apache entwickelt wurde, um das C10k-Problem zu lösen – das bedeutet: 10.000 gleichzeitige Verbindungen auf einem einzigen Server zu verwalten. Während Apache für jede eingehende Verbindung einen eigenen Prozess oder Thread startet, nutzt Nginx ein ereignisgesteuertes, asynchrones Modell, bei dem ein einzelner Worker-Prozess Tausende Verbindungen gleichzeitig verwaltet. Daher verbraucht Nginx unter hoher Last dramatisch weniger RAM als Apache. Für WordPress bedeutet das: Nginx ist besonders gut geeignet für Seiten mit hohem Traffic oder viel statischem Content (Bilder, CSS, JS), weil es diese Dateien über den nativen sendfile()-Syscall des Betriebssystems direkt ausliefert. Apache hat dagegen den Vorteil der .htaccess-Unterstützung, die WordPress für Permalink-Rewriting automatisch nutzt.
Kann ich auf Shared Hosting zu Nginx wechseln?
Ein vollständiger Wechsel zu Nginx ist auf Shared Hosting in den meisten Fällen nicht möglich, weil Shared Hosting keinen Root-Zugriff bietet und Apache standardmäßig vorkonfiguriert ist. Jedoch gibt es eine Ausnahme: cPanel-Server mit aktiviertem EA-Nginx-Modul können Nginx als Reverse Proxy vor Apache schalten, was statische Dateien über Nginx ausliefert und PHP-Requests weiterhin über Apache verarbeitet. Diese Kombination ist der empfohlene Mittelweg für cPanel-Umgebungen, weil .htaccess vollständig erhalten bleibt. Ein vollständiger Nginx-Stack ohne Apache ist dagegen nur auf VPS- oder Root-Servern möglich, weil dort die Webserver-Konfiguration komplett selbst kontrolliert wird.
Wie konfiguriere ich WordPress-Permalinks auf Nginx?
WordPress-Permalinks auf Nginx werden über die try_files-Direktive im Server-Block konfiguriert. Die Konfiguration lautet: location / mit try_files $uri $uri/ /index.php?$args. Ohne diese Zeile liefert Nginx bei allen WordPress-Unterseiten einen 404-Fehler, weil Nginx nicht weiß, dass fehlende Dateien an index.php weitergeleitet werden sollen. Anders als bei Apache ist diese Konfiguration statisch und ändert sich nicht, wenn WordPress-Permalinks in der Einstellungsseite geändert werden – weil die Regel universell ist und alle Anfragen an WordPress weiterleitet. Daher ist nach einer Permalink-Änderung in WordPress auf Nginx kein Server-Reload nötig, was gegenüber Apache ein Vorteil bei wartungsintensiven Installationen ist.
Wie schnell ist Nginx FastCGI-Cache im Vergleich zu WP Rocket?
Nginx FastCGI-Cache ist schneller als jede Plugin-basierte Cache-Lösung, weil die gecachte Antwort ausgeliefert wird, bevor PHP-FPM und WordPress überhaupt gestartet werden. WP Rocket und ähnliche Plugins benötigen mindestens einen PHP-Prozess für die Cache-Auslieferung – weil WordPress zuerst booten muss, um zu entscheiden, ob der Cache aktiv ist. Nginx antwortet bei Cache-HIT in unter 5 ms, WP Rocket typischerweise in 20 bis 50 ms. Das ist ein erheblicher Unterschied bei hohem Traffic. Jedoch hat WP Rocket den Vorteil, dass es keine Server-Konfiguration erfordert und auf Shared Hosting verfügbar ist. Daher ist die Wahl zwischen beiden nicht entweder/oder: Auf Shared Hosting ist WP Rocket die beste verfügbare Option, auf VPS mit Nginx-Zugriff ist FastCGI-Cache die überlegene Lösung.
Was kostet die Umstellung von Apache auf Nginx für WordPress?
Die Umstellung von Apache auf Nginx für WordPress ist kein Plug-and-Play-Vorgang und erfordert technisches Know-how auf Server-Ebene. Weil Nginx keine .htaccess liest, müssen alle bisher in der .htaccess konfigurierten Regeln – Redirects, Sicherheitsregeln, Cache-Header – manuell in die Nginx-Konfiguration übertragen werden. Außerdem müssen alle installierten Plugins geprüft werden, die .htaccess-Regeln schreiben. Folglich ist der Umstellungsaufwand stark abhängig von der Komplexität der bestehenden .htaccess-Konfiguration. Als Orientierung: Eine einfache WordPress-Installation mit Standard-Permalink-Struktur kann in zwei bis drei Stunden vollständig migriert werden. Komplexe Setups mit vielen Redirect-Regeln und Sicherheits-Plugins erfordern mehr Zeit für Tests und Validierung.
Weiterführende Ressourcen: Nginx-Dokumentation (nginx.org), Apache HTTP Server Dokumentation (apache.org), WordPress Nginx-Konfiguration (developer.wordpress.org)
Autor: Manuel Kuhn, WordPress Performance Engineer & Serveradministrator, Hosting-Fixers.de – Juli 2026