Apache vs. NGINX: Welcher Webserver ist der beste für WordPress?

Wenn Sie WordPress auf Ihrem eigenen VPS betreiben, können Apache und NGINX die Website beide gut ausliefern, aber sie gehen unterschiedliche Kompromisse ein. NGINX ist meist die bessere Standardwahl bei hoher Nebenläufigkeit, bei der Auslieferung statischer Dateien und für optionales HTTP/3. Apache ist einfacher, wenn Ihr WordPress-Stack auf .htaccess oder Apache-spezifische Module angewiesen ist.

Dieser Vergleich zwischen Apache und NGINX konzentriert sich auf die Unterschiede, die für WordPress zählen: Architektur, PHP-Handhabung, Konfiguration, HTTP/3 und die Frage, ob sich der Betrieb beider Server lohnt. LiteSpeed und Caddy bleiben außen vor.

Kurze Antwort: Für einen selbstverwalteten WordPress-VPS ist NGINX die Standardwahl. Nehmen Sie Apache, wenn Ihre Website oder Ihre Plugins stark von .htaccess abhängen. Betreiben Sie beide nur, wenn Sie NGINX wirklich davor brauchen, ohne die Apache-Kompatibilität aufzugeben.

Was ist Apache?

Apache ist eine weit verbreitete Open-Source-Webserver-Software, die von der US-amerikanischen gemeinnützigen Organisation Apache Software Foundation (ASF) entwickelt und gepflegt wird. Sie ist auch als Apache HTTP Server und HTTPD bekannt.

Die Download-Seite von Apache führt 2.4.68, veröffentlicht im Juni 2026, als aktuelle stabile Version auf.

Apache HTTP Server ist ein modularer Open-Source-Server mit ausgereifter Unterstützung für verzeichnisbezogene .htaccess-Regeln, mehrere Multi-Processing-Module (MPMs), Reverse Proxying, URL-Rewriting, TLS und dynamisch geladene Module. Für WordPress liegt sein größter praktischer Vorteil in der Konfigurationskompatibilität, nicht in der reinen Geschwindigkeit.

Die Apache-Funktionen, die in diesem Vergleich am wichtigsten sind, sind die MPMs prefork, worker und event; .htaccess; HTTP/2; Reverse Proxying und Lastverteilung; FastCGI-Unterstützung; dynamische Module; URL-Rewriting; und TLS.

Was ist NGINX?

NGINX („engine x“) ist ein Open-Source-Webserver, Reverse Proxy, Content-Cache, Load Balancer, TCP/UDP-Proxy und Mail-Proxy, ursprünglich geschrieben von Igor Sysoev. Seine Worker-Prozesse arbeiten ereignisgesteuert und sind darauf ausgelegt, viele gleichzeitige Verbindungen mit geringem Aufwand pro Verbindung zu bedienen.

Die Download-Seite von NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache vs. NGINX: die wichtigsten Unterschiede für WordPress

Apache und NGINX unterscheiden sich am deutlichsten darin, wie sie Verbindungen, Konfiguration, PHP und Protokollunterstützung handhaben. Das Verhalten von Apache hängt stark vom verwendeten MPM ab, während NGINX ereignisgesteuerte Worker-Prozesse einsetzt.

Apache vs. NGINX: Architektur

Das Request-Modell von Apache hängt vom eingesetzten MPM ab. Prefork arbeitet prozessbasiert, worker und event nutzen Threads. NGINX setzt auf Worker-Prozesse, die um Ereignisschleifen herum gebaut sind. Der vertraute Vergleich „prozessgesteuertes Apache gegen ereignisgesteuertes NGINX“ ist damit für ein aktuelles Apache-2.4-Setup zu simpel.

Das event-MPM von Apache kann inaktive Keep-alive-Verbindungen an seinen Listener-Thread übergeben, statt für jede Verbindung einen Worker-Thread zu binden. NGINX hat bei sehr vielen gleichzeitigen Verbindungen weiterhin tendenziell weniger Aufwand pro Verbindung, aber der architektonische Abstand ist deutlich kleiner, als alte Vergleiche aus der prefork-Ära nahelegen.

Apache vs. NGINX: Performance

Der Performance-Vorteil von NGINX zeigt sich vor allem bei hoher Nebenläufigkeit und bei statischen Dateien. Seine ereignisgesteuerten Worker können viele Verbindungen mit vergleichsweise geringem Aufwand pro Verbindung offen halten. Das event-MPM von Apache verkleinert diesen Abstand gegenüber älteren prefork-Konfigurationen deutlich.

Bei dynamischen WordPress-Anfragen sieht es anders aus. NGINX reicht PHP normalerweise an FastCGI weiter, meist an PHP-FPM. Apache kann PHP-FPM ebenfalls über FastCGI nutzen oder PHP über ein Apache-Modul ausführen.

Sobald PHP anfängt, WordPress auszuführen, können Plugin-Code, Datenbankabfragen, Objekt- oder Seiten-Caching und die Dimensionierung der PHP-Worker mehr ausmachen als der Webserver davor. Wenn ein Plugin pro Anfrage ein Dutzend teure Datenbankabfragen absetzt, löst der Wechsel von Apache zu NGINX das eigentliche Problem nicht.

Apache vs. NGINX: Unterstützung für HTTP/3 und QUIC

HTTP/3 ist die aktuelle Version des Protokolls und läuft über QUIC statt über TCP. Ob Ihre Website es überhaupt anbieten kann, hängt vom davorliegenden Webserver ab, und das ist der eine Vergleichspunkt, an dem die beiden Server nicht dicht beieinanderliegen.

NGINX liefert seit Version 1.25.0 ein HTTP/3-Modul mit. Es wird nicht standardmäßig gebaut, und der Build benötigt den Parameter --with-http_v3_module.

Die Dokumentation des HTTP/3-Moduls von NGINX bezeichnet das Modul weiterhin als „experimental, caveat emptor applies“.

Apache 2.4 bringt kein natives HTTP/3- oder QUIC-Modul mit; die mitgelieferte Protokollunterstützung endet bei mod_http2.

Die praktische Folge für Website-Betreiber: Eine gewöhnliche Apache-2.4-Installation bietet kein HTTP/3. Im Produktivbetrieb bleibt die praktikable Option, HTTP/3 auf einem HTTP/3-fähigen Reverse Proxy oder CDN vor Apache zu terminieren. Wenn Sie das Protokoll wollen, können Sie NGINX vor Apache stellen und die Client-Verbindungen von NGINX terminieren lassen, genau die Anordnung, die weiter unten beschrieben wird.

Apache vs. NGINX: Sicherheit

Weder Apache noch NGINX ist pauschal „sicherer“. Beide sind ausgereifte Projekte mit aktiver Sicherheitspflege, und die Sicherheit eines Produktivsystems hängt vor allem von Patches, aktivierten Modulen, TLS-Konfiguration, Zugriffskontrollen, Ratenbegrenzungen und der Anwendung hinter dem Server ab.

Sinnvoll zu vergleichen sind Angriffsfläche und Konfiguration, nicht ein pauschaler Sieger. Deaktivieren Sie Module und Endpunkte, die Sie nicht brauchen, halten Sie den Server gepatcht und härten Sie den WordPress-Stack dahinter.

Apache vs. NGINX: Konfiguration

Die verzeichnisbezogenen .htaccess-Dateien von Apache funktionieren, sobald AllowOverride sie erlaubt. Das ist für WordPress praktisch, weil sich Rewrite-Regeln ändern lassen, ohne die globale Serverkonfiguration anzufassen.

Dieser Komfort hat seinen Preis. Die eigene Dokumentation von Apache empfiehlt, die Regeln in die Hauptkonfiguration des Servers zu schreiben, wenn Sie Root-Zugriff haben: .htaccess-Dateien werden bei jeder Anfrage geprüft, und ihre Aktivierung wirft sowohl Performance- als auch Sicherheitsfragen auf.

NGINX hat kein Gegenstück zu .htaccess. Seine Konfiguration ist zentral, WordPress kann also keine Rewrite-Regeln auf Serverebene für Sie schreiben. Permalink-Regeln und Plugin-spezifische Serverdirektiven muss ein Administrator in die NGINX-Konfiguration eintragen und anschließend neu laden.

Apache vs. NGINX: Module und Erweiterbarkeit

Apache unterstützt Dynamic Shared Objects (DSO) seit Langem ausgereift: Module lassen sich separat kompilieren und über LoadModule laden. NGINX unterstützt dynamisch geladene Module ebenfalls über load_module, aber die binäre Kompatibilität mit der installierten NGINX-Version und deren Build-Konfiguration wiegt schwerer, sobald Sie nicht-standardmäßige Drittanbietermodule einsetzen.

Apache hat also die Nase vorn, wenn Sie auf ungewöhnliche Drittanbietermodule angewiesen sind. Für gewöhnliches WordPress-Hosting fällt dieser Unterschied meist weniger ins Gewicht als .htaccess, die PHP-Anbindung und Ihr bestehendes Werkzeug.

Apache vs. NGINX: Plattformunterstützung

Apache läuft auf Linux, Windows, macOS und vielen unixartigen Systemen. NGINX gibt es ebenfalls für die wichtigsten Plattformen, doch der native Windows-Build hat erhebliche Einschränkungen. NGINX bezeichnet die Windows-Version weiterhin als Beta, weist darauf hin, dass man keine hohe Performance und Skalierung erwarten sollte, hält fest, dass nur ein Worker tatsächlich Arbeit übernimmt, und unterstützt weder UDP noch QUIC. Für den produktiven NGINX-Einsatz ist ein unixartiges Betriebssystem die praktikable Wahl.

Apache vs. NGINX: Verarbeitung von Anfragen

Apache bildet die URL einer Anfrage normalerweise auf das Dateisystem unterhalb von DocumentRoot ab, während sein Konfigurationssystem zusätzlich URI-basierte Locations, Rewrites und Proxy-Regeln anwenden kann. NGINX wählt zuerst einen server-Block und dann einen location-Block, im Wesentlichen anhand der Anfrage-URI, und entscheidet erst danach, ob es eine Datei ausliefert oder die Anfrage nach oben weiterreicht.

Dieser Unterschied prägt, wie Sie Konfiguration schreiben, ist für sich genommen aber kein Beleg dafür, dass NGINX Daten schneller überträgt.

Ein kurzer Vergleich zwischen NGINX und Apache

So stehen die beiden Server bei den oben genannten Punkten zueinander, dazu die Protokollunterstützung und die aktuelle Version jedes Servers.

Apache und NGINX zusammen betreiben

Ja, Sie können beide betreiben. Ein verbreitetes hybrides Layout stellt NGINX als clientseitigen Reverse Proxy nach vorn und Apache dahinter. NGINX kann TLS und HTTP/2 terminieren, und HTTP/3, sobald das experimentelle HTTP/3-Modul gebaut und aktiviert ist. Es kann außerdem ausgewählte statische Dateien selbst ausliefern und Anwendungsanfragen an Apache weiterreichen.

Der entscheidende Vorbehalt ist die Zuständigkeit für Regeln. Eine Anfrage, die NGINX direkt beantwortet, erreicht Apache nie, also greifen dort auch keine .htaccess-Regeln von Apache. Beide Konfigurationen müssen sich über Rewrites, Caching, die Weitergabe der Client-IP, das TLS-Verhalten und darüber einig sein, welcher Server welchen Pfad verantwortet.

Der Preis ist, dass Sie jetzt zwei Webserver betreiben. Zwei Konfigurationen, die zueinander passen müssen, zwei Update-Zyklen im Blick, und eine zusätzliche Stelle, an der Sie nachsehen müssen, wenn eine Anfrage etwas Unerwartetes liefert. Bei einer einzelnen kleinen Website überwiegt dieser Aufwand meist den Nutzen; er lohnt sich, wenn Sie HTTP/3 oder schnellere Auslieferung statischer Dateien wollen, ohne auf das .htaccess-Verhalten Ihrer Plugins zu verzichten.

Ist NGINX einfacher als Apache?

Keiner der beiden ist grundsätzlich einfacher. NGINX ist einfacher, wenn Sie eine zentrale Konfiguration bevorzugen und sich beim Bearbeiten von server-Blöcken wohlfühlen. Apache ist einfacher, wenn WordPress oder Drittanbieter-Plugins .htaccess-Regeln erwarten, denn diese Regeln wirken auf Verzeichnisebene, ohne die globale Serverkonfiguration zu ändern.

Auf einem Server, den Sie kontrollieren, läuft „einfacher“ vor allem darauf hinaus, welches Konfigurationsmodell Ihr Stack ohnehin erwartet.

Wann sollten Sie Apache statt NGINX nehmen?

Nehmen Sie Apache, wenn Ihr WordPress-Stack von .htaccess abhängt, wenn Plugins oder Control-Panel-Werkzeuge Apache-Rewrite-Direktiven erwarten oder wenn Sie ein bestimmtes Apache-Modul brauchen. Es ist außerdem vernünftig, Apache auf einer bestehenden Website zu belassen, die gut läuft: Ein Serverwechsel für einen theoretischen Benchmark-Gewinn ist die Störung selten wert.

Wann sollten Sie NGINX statt Apache nehmen?

Nehmen Sie NGINX, wenn Sie viele gleichzeitige Verbindungen erwarten, eine starke Schicht für statische Dateien oder Reverse Proxying wollen, eine zentrale Konfiguration bevorzugen oder sich die Option auf HTTP/3 offenhalten möchten. Für WordPress ist der Preis, dass Rewrite-Regeln und plugin-spezifische Serverdirektiven zur Administratoraufgabe werden statt etwas, das WordPress in .htaccess schreiben kann.

NGINX vs Apache: Welcher Web-Server ist der richtige für WordPress?

Nehmen Sie NGINX. Für eine WordPress-Website auf einem Server, den Sie kontrollieren, ist es die bessere Standardwahl: geringer Verbindungsaufwand bei hoher Nebenläufigkeit, effiziente Auslieferung statischer Dateien und HTTP/3, wenn Sie es wollen.

Die Ausnahme ist .htaccess, und sie wiegt schwer. WordPress kann Apache-Rewrite-Regeln schreiben, wenn .htaccess aktiv ist, aber es kann die Serverkonfiguration von NGINX nicht ändern. Erwartet ein Plugin Rewrite-, Sicherheits- oder Caching-Direktiven, brauchen Sie dessen NGINX-Anleitung oder eine gleichwertige Regel im server-Block und danach ein Neuladen von NGINX. Wenn Sie diese Betriebsverantwortung nicht wollen, ist Apache die einfachere WordPress-Wahl. Auf einer Website mit normalem Traffic begrenzen PHP, Datenbank und Caching die Performance eher als der Webserver selbst.

Unter alldem liegt eine Annahme: Der Server muss Ihnen gehören und veränderbar sein. Bei Managed WordPress-Hosting entscheidet der Anbieter über den Webserver, und die Antwort auf diese Frage ist schlicht das, was dort ohnehin läuft. Dieser Vergleich richtet sich an jemanden mit Root-Zugriff auf der eigenen Maschine.

Wie prüfen Sie, ob Apache oder NGINX läuft?

Wenn es Ihr eigener VPS ist, prüfen Sie die laufenden Dienste direkt:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Bei einer fremden Website, die Sie nicht kontrollieren, kann der HTTP-Antwort-Header Server ein Hinweis sein, aber kein Beweis. Ein Reverse Proxy oder CDN kann seine eigene Serversoftware anzeigen statt der des Ursprungsservers, und der Header lässt sich außerdem verbergen oder ändern.

Apache oder NGINX auf einem VPS betreiben

Wenn Ihnen der VPS gehört, lassen sich beide Server unkompliziert betreiben. Dimensionieren Sie die Maschine für den gesamten WordPress-Stack, nicht nur für Apache oder NGINX: PHP-Worker, Datenbank, Caching, Traffic und Hintergrundjobs verbrauchen meist mehr Ressourcen als der Webserver selbst.

Für welchen Server Sie sich auch entscheiden: Konfiguration, Updates, TLS, Backups und Monitoring liegen bei Ihnen. Beide zu betreiben bringt eine zusätzliche Konfiguration und einen zusätzlichen Update-Pfad mit sich. Nutzen Sie das hybride Setup daher nur, wenn Sie einen konkreten Grund dafür haben.

Der NGINX-VPS von Cloudzy ist ein selbstverwalteter Linux-VPS mit vollem Root-Zugriff, die Serverkonfiguration bleibt also Ihre.

Das Apache-HTTP-Server-Image in unserem Marketplace installiert sich genauso, mit einem Klick, sodass das Aufsetzen des einen oder beider Server nicht mit dem Kompilieren aus den Quellen beginnt.

LESEN

Caddy vs. Nginx auf einem VPS: Der Vergleich der Konfigurationsdateien

Häufig gestellte Fragen

Ist Apache besser als NGINX?

Keiner ist grundsätzlich besser. NGINX ist meist die stärkere Standardwahl, wenn Ihnen hohe Nebenläufigkeit, statische Auslieferung, Reverse Proxying oder HTTP/3 wichtig sind. Apache ist meist einfacher, wenn Ihr WordPress-Stack von .htaccess oder Apache-spezifischen Modulen abhängt.

Warum ist NGINX schneller als Apache?

NGINX kann viele Verbindungen innerhalb der Ereignisschleife jedes Workers abwickeln, was den Aufwand pro Verbindung bei hoher Nebenläufigkeit gering hält. Das event-MPM von Apache behandelt Verbindungen ebenfalls asynchron, der Abstand ist also kleiner, als alte prefork-Vergleiche nahelegen. Bei WordPress können PHP, Datenbankabfragen und Caching mehr ausmachen als der Unterschied zwischen den Webservern.

Sollte ich für WordPress Apache oder NGINX nehmen?

Für einen selbstverwalteten WordPress-VPS ist NGINX eine gute Standardwahl, wenn Sie die Regeln in den server-Blöcken selbst pflegen wollen. Nehmen Sie Apache, wenn Sie auf .htaccess setzen oder Plugins nutzen, die Apache-Rewrite-Regeln erwarten, und wollen, dass diese mit weniger manueller Serverkonfiguration funktionieren.

Warum ist NGINX so beliebt?

NGINX verbindet effiziente Anfrageverarbeitung bei hoher Nebenläufigkeit mit Reverse Proxying, Lastverteilung, Caching, FastCGI-Unterstützung und TLS-Terminierung. Das macht es sowohl als primären Webserver als auch als vorgelagerten Proxy nützlich.

Warum wird Apache immer noch eingesetzt?

Apache ist weiterhin weit verbreitet, dank seines Modul-Ökosystems, der .htaccess-Unterstützung, ausgereifter Werkzeuge, breiter Plattformunterstützung und der Kompatibilität mit Hosting- und Control-Panel-Workflows, die um Apache herum gebaut sind.

Was ist der Unterschied zwischen Apache und apache2?

Unter Debian und Ubuntu ist apache2 der Paket- und Dienstname von Apache HTTP Server. Systeme der RHEL- und Fedora-Familie nennen den Dienst üblicherweise httpd. Es sind keine unterschiedlichen Webserver: Beide bezeichnen Apache HTTP Server. Der aktuelle stabile Apache-Zweig ist 2.4, mit 2.4.68 als jüngster Version.

Unterstützt Apache HTTP/3?

Nicht von Haus aus. Apache HTTP Server 2.4 bringt kein HTTP/3- oder QUIC-Modul mit; die mitgelieferte Protokollunterstützung endet bei HTTP/2. Wenn Sie HTTP/3 im Produktivbetrieb brauchen, können Sie es auf einem HTTP/3-fähigen Reverse Proxy oder CDN vor Apache terminieren.