Ihre WordPress-Website kriecht mit nur 50 Besuchern, obwohl der Server nicht unter Last steht? Eine vertraute Situation für jeden, der günstiges Hosting auf Apache gebucht hat, ohne sich den Stack anzusehen. Der Grund ist fast immer derselbe: Der Webserver kommt mit gleichzeitigen Verbindungen nicht zurecht.

Den Hoster zu wechseln löst das Problem. Aber wichtiger ist, dass Sie verstehen, welcher Webserver hinter Ihrem Tarif steckt. Das entscheidet darüber, ob Ihre Site einen Traffic-Anstieg übersteht oder abstürzt, nachdem jemand sie auf Telegram teilt.

Nachfolgend ohne Umschweife: wie Apache und nginx funktionieren, die praktischen Unterschiede und warum nginx im Jahr 2026 zum Standard für WordPress-Hosting geworden ist.

💡 Kurzüberblick:

• Ein Webserver nimmt HTTP-Anfragen vom Browser entgegen und liefert eine Antwort: Er stellt statische Dateien direkt bereit und verarbeitet dynamische Inhalte über eine PHP-Anbindung.
• Apache erzeugt für jede Verbindung einen Prozess. Flexibel, aber unter Last geht der Arbeitsspeicher aus. Nginx nutzt eine ereignisgesteuerte Architektur und bewältigt Tausende Verbindungen in einem einzigen Prozess.
• Für WordPress sind gleichzeitige Verbindungen, Cache-Behandlung und Speicherverbrauch entscheidend. Nginx gewinnt auf allen drei Feldern.
• Hosting auf nginx bringt Ihnen eine schnellere Website bei gleichem Tarif. Wollen Sie Ihres prüfen? Fragen Sie den Support nach dem Webserver-Stack.

Was ein Webserver ist und warum WordPress einen braucht

Ein Webserver ist ein Programm, das HTTP-Anfragen entgegennimmt und eine Antwort zurückgibt. Wenn ein Besucher eine Website öffnet, kontaktiert der Browser den Server, der eine HTML-Seite zurücksendet. Bei WordPress ist der Ablauf etwas komplexer: Ein PHP-Prozessor setzt die Seite aus Template und Datenbank zusammen, und der Webserver liefert das Ergebnis an den Nutzer aus.

Zwei Open-Source-Webserver dominieren den Markt: Apache und nginx. Laut W3Techs-Daten vom Juni 2026 bedient nginx 31,9% der Websites mit bekanntem Webserver, Apache 23,9%. Zusammen decken sie mehr als die Hälfte des Internets ab. Microsofts IIS folgt mit deutlichem Abstand auf Platz drei.

Der Unterschied zwischen ihnen ist nicht kosmetischer Natur. Er wirkt sich unmittelbar darauf aus, wie viele Besucher Ihre Website gleichzeitig verkraftet und wie schnell Seiten laden.

Apache: bewährt, aber schwergewichtig

Der Apache HTTP Server erschien 1995 und war jahrzehntelang der Standard. Er ist die Grundlage von cPanel, dem verbreitetsten Hosting-Control-Panel. Die meisten Shared-Hoster betreiben Apache noch immer, einfach weil „es schon immer so war".

Apaches Stärke ist die Modularität. Sie können Module dynamisch laden und das Serververhalten über .htaccess direkt im Website-Ordner anpassen, ohne Neustart. Für Entwickler ist das komfortabel: eine Weiterleitung einrichten, den Zugriff auf eine Datei sperren, Caching konfigurieren, alles mit Regeln in einer Textdatei.

Doch diese Flexibilität hat ihren Preis. Apache erzeugt für jede Verbindung einen eigenen Thread oder Prozess. Bei 100 gleichzeitigen Besuchern sind das 100 Prozesse. Bei 500 geht der Speicher aus, der Server antwortet verzögert oder verwirft Verbindungen. Man spricht vom C10K-Problem (10.000 gleichzeitige Verbindungen), das Apache in seinem Standardmodus nicht bewältigen kann.

In der Praxis wird eine Website auf Apache ohne zusätzliches Caching bereits bei wenigen Dutzend gleichzeitigen Nutzern spürbar langsam. WordPress mit seiner dynamischen Natur verschärft das Problem: Jede Anfrage führt PHP aus, das die Datenbank abfragt, und der Prozess hängt, bis alles vollständig abgeschlossen ist.

Nginx: der ereignisgesteuerte Ansatz und warum er schneller ist

Igor Sysoev schrieb nginx 2002 gezielt, um das C10K-Problem zu lösen. Die erste öffentliche Version erschien 2004. Anders als Apache basiert nginx auf einer ereignisgesteuerten Architektur: Ein einzelner Worker-Prozess bedient Tausende Verbindungen, ohne für jede einen eigenen Thread zu erzeugen.

So funktioniert es. Nginx lauscht auf Ereignisse an Sockets und reagiert nur, wenn Daten zu verarbeiten sind. Neue Anfrage trifft ein, wird verarbeitet. Client ist langsam beim Empfangen der Antwort, keine Blockade, Wechsel zur nächsten. Dieser asynchrone Ansatz ist genau das, was nginx erlaubt, mehr Verbindungen mit weniger Speicher zu bewältigen.

Nginx hat eine Einschränkung: Es kann dynamische Inhalte nicht selbst verarbeiten. Es braucht einen externen Handler: PHP-FPM, FastCGI oder einen Proxy zu Apache. In der Praxis ist das jedoch kein Nachteil, sondern ein Vorteil: Die dynamische Verarbeitung ist isoliert, stört die Auslieferung statischer Dateien nicht, und jede Komponente lässt sich unabhängig konfigurieren.

Historisch gesehen war das Hauptproblem von nginx die Dokumentation. Sysoev verfasste sie auf Russisch, und frühe Versionen litten unter spärlichen Beschreibungen. Inzwischen ist die Dokumentation übersetzt, die Community riesig, und es gibt fertige Konfigurationen für WordPress, die jedes Szenario abdecken. DigitalOcean beispielsweise pflegt detaillierte Anleitungen für die Kombination nginx + WordPress.

Ein weiterer Unterschied: nginx kann Module nicht dynamisch laden und unterstützt kein .htaccess. Alle Einstellungen stehen in Server-Konfigurationsdateien, und deren Anwendung erfordert einen Reload. Das ist für tägliche Anpassungen weniger bequem, bietet aber Vorhersagbarkeit: Der Server durchsucht Verzeichnisse nicht zur Laufzeit nach Regeln und verbraucht dafür keine CPU-Zeit.

Sechs Gründe, sich für nginx bei WordPress zu entscheiden

Konkrete Argumente, warum nginx Apache bei einer WordPress-Website schlägt.

Einfache Installation

Nginx installiert sich mit einem einzigen Befehl auf jeder Linux-Distribution:

1
apt install nginx

Oder für RHEL/CentOS:

1
yum install nginx

Nach der Installation funktioniert nginx sofort als Dienst. Für WordPress müssen Sie PHP-FPM und eine minimale Konfiguration ergänzen: eine typische Config von 20 Zeilen, die sich von Projekt zu Projekt nicht ändert.

Proxy-Modus für Apache

Wenn Ihre Website bereits auf Apache läuft und Ihnen eine Migration zu riskant erscheint, können Sie nginx als Reverse-Proxy davorschalten. Alle statischen Inhalte laufen über nginx, während es PHP-Anfragen an Apache weiterleitet. Sie sehen sofort Leistungsgewinne, und .htaccess samt der vertrauten modularen Struktur funktioniert weiter.

Das Schema sieht so aus: Browser → nginx (statisch + Cache) → Apache (nur PHP). Laut Benchmarks bringt selbst dieses Setup eine Verdopplung der verarbeiteten Anfragen pro Sekunde.

Integrierter Cache

Nginx verfügt über fastcgi_cache, der PHP-FPM-Antworten zwischenspeichert und als statische Dateien ausliefert. Für WordPress ist das transformativ: Eine einmal zusammengesetzte Seite fliegt aus dem Cache zu allen nachfolgenden Besuchern, ohne PHP zu starten oder die Datenbank abzufragen.

In der Praxis reduziert ein gut konfigurierter fastcgi_cache die Server-Antwortzeit von 600-800 ms auf 20-40 ms. Kein externes Caching-Plugin für WordPress kann diesen Effekt auf Serverebene erreichen.

Schnellere Auslieferung statischer Dateien

Bilder, CSS, JavaScript, Schriften: Alles, was kein PHP benötigt, liefert nginx direkt und ohne zusätzliche Schichten aus. Eine einzige try_files-Direktive ersetzt ein Dutzend Apache-Regeln. Das Ergebnis: Statische Dateien werden in Millisekunden ausgeliefert, und PHP-Worker sind nicht mit Hilfsarbeiten blockiert.

Mehr Verbindungen bei geringerem Verbrauch

Nginx bewältigt bei vergleichbarem Speicherverbrauch rund viermal mehr gleichzeitige Verbindungen als Apache. Das ist keine abstrakte Zahl: W3Techs-Daten zeigen, dass nginx bei Websites mit hohem Traffic einen Anteil von über 60% hält.

Zwei praktische Vorteile für einen WordPress-Site-Betreiber:

• Wenn der Traffic wächst, müssen Sie nicht sofort auf einen teureren Tarif upgraden.
• Der Server verbraucht weniger CPU und RAM, sodass der Hoster die Preise niedriger halten oder mehr Ressourcen für dasselbe Geld bereitstellen kann.

Schlankes Design

Nginx ist darauf ausgelegt, minimale Ressourcen zu verbrauchen. Der Worker-Prozess lauscht auf Ereignisse und wird nur bei Bedarf aktiv. Die Konfigurationsoption on demand kann ungenutzte Worker sogar aus dem Speicher entladen.

Apache versuchte, einen ereignisgesteuerten Modus über mpm_event zu implementieren, aber das ist ein Aufsatz auf einer prozessbasierten Architektur, keine Neuentwicklung. Die Leistung von mpm_event erreicht nginx gerade deshalb nicht, weil Apache ursprünglich anders gebaut wurde.

Lastverteilung

Nginx kann Anfragen auf mehrere Backend-Server verteilen. Für ein WordPress-Projekt mit hohem Traffic bedeutet das: Sie können zwei oder drei Anwendungsserver betreiben, nginx als Load Balancer davorschalten, und Ihre Website verkraftet Zehntausende gleichzeitige Besucher. Große WordPress-Hoster wie WP Engine und Kinsta nutzen genau diese Architektur.

⁉️🤔 Häufig gestellte Fragen

Muss ich zu nginx wechseln, wenn meine Website auf Apache problemlos läuft?

Wenn Ihre Website beim aktuellen Traffic-Niveau stabil läuft, gibt es keinen dringenden Bedarf für einen Wechsel. Planen Sie jedoch Wachstum, schalten Werbung oder erwarten saisonale Spitzen, setzen Sie nginx als Proxy vor Apache. Das verschafft Ihnen einen Leistungspuffer ohne vollständige Migration.

Stimmt es, dass nginx für WordPress schwieriger zu konfigurieren ist?

Die Grundeinrichtung besteht aus einer Konfigurationsdatei und einem Standardsatz an Regeln für sprechende Permalinks. DigitalOcean und WordPress.org veröffentlichen getestete Konfigurationen. Der Unterschied zu Apache: Statt .htaccess zu bearbeiten, editieren Sie nginx.conf und führen nginx -s reload aus. Es fühlt sich anfangs etwas ungewohnt an, aber die Config ist besser lesbar.

Welches Hosting soll ich wählen: nginx out of the box oder einen beliebigen Hoster mit nginx als Proxy?

Wenn Sie Managed WordPress buchen, stellen Sie sicher, dass nginx als primärer Webserver im Stack steckt. WP Engine, Kinsta und Rocket.net arbeiten genau so. Nutzen Sie einen VPS, richten Sie nginx + PHP-FPM ein: Das ist der Standard für WordPress im Jahr 2026. Shared Hosting mit nginx als Proxy vor Apache ist ein Kompromiss, aber dennoch eine gewinnbringende Option.

Verliere ich etwas Wichtiges beim Wechsel von Apache zu nginx?

Sie verlieren .htaccess. Alles, was Sie darüber angepasst haben (Weiterleitungen, Zugriffsbeschränkungen, Caching), wird einmalig und zentral in die nginx-Konfiguration überführt. WordPress-Plugins, die auf .htaccess angewiesen sind (etwa manche Sicherheits-Plugins), erfordern möglicherweise eine manuelle Anpassung der Regeln. Aber große Plugins enthalten seit Langem nginx-Konfigurationen.

Hat Apache bei WordPress eine Zukunft?

Apache verschwindet nicht: Zu viel Hosting-Infrastruktur ist darauf aufgebaut. Aber der Trend ist klar: Apaches Anteil sinkt, der von nginx steigt. Neue WordPress-Projekte und -Hoster starten standardmäßig mit nginx. Wenn Sie von Grund auf neu beginnen, starten Sie mit nginx.

Nginx oder Apache: Was man 2026 einsetzt

Kurz gesagt: Entscheiden Sie sich für WordPress für nginx. Nicht weil Apache schlecht ist, sondern weil nginx einen spezifischen Schmerzpunkt löst, viele Besucher auf bescheidener Hardware bewältigt und Inhalte schneller ausliefert.

Handlungsplan für drei typische Situationen:

• Neue Website starten. Buchen Sie Hosting mit nginx im Stack oder richten Sie einen VPS mit nginx + PHP-FPM ein. Es gibt Dutzende Vorlagen-Konfigurationen für WordPress, keine Konfigurationsschwierigkeiten.
• Website läuft bereits auf Apache und ist langsam. Schalten Sie nginx als Reverse-Proxy davor. Das kostet etwa eine Stunde Admin-Arbeit und bringt sofortige Leistungsgewinne.
• Website auf Apache, alles ist schnell. Machen Sie weiter. Bedenken Sie aber, dass nginx Ihnen bei wachsendem Traffic mehr Spielraum gibt als der Versuch, aus Apache noch mehr herauszupressen.

Prüfen Sie Ihren aktuellen Stack: Gehen Sie in Ihr Hosting-Dashboard oder fragen Sie den Support. Wenn Sie „nginx" hören, gut. Wenn „Apache", wissen Sie jetzt, was zu tun ist.