„Wir wechseln zu Nginx“ kommt bei jedem Audit zur Sprache – manchmal aus gutem Grund, manchmal weil es in einem Blog aus dem Jahr 2014 so stand. Allerdings hostet der gemeinsam genutzte Apache dank „.htaccess“ immer noch Tausende von WordPress ohne Notfall. Und moderne Stacks führen Nginx vor Apache aus, gerade weil niemand die Regeln migriert hat.
Nginx und Apache sind keine zwei Religionen. Dies sind zwei Punkte im Abfragepfad mit unterschiedlicher Stärke. Wenn man „das Beste“ wählt, ohne HTTP → PHP → statisch → Cache zuzuordnen, wird die falsche Stufe optimiert.
Ordnen Sie den Pfad einer Anfrage zu
Bevor Sie Benchmarks vergleichen, überlegen Sie, was passiert, wenn ein Besucher eine Seite lädt. Läuft die Anfrage zuerst über ein CDN? Stellt der Webserver statische Dateien direkt bereit oder wird alles an PHP zurückgegeben? Wer kann die Rewrite-Regeln ändern – das technische Team oder der Kunde über „.htaccess“?
| Schritt | Nginx-Rolle | Apache-Rolle |
|---|---|---|
| TLS-Terminierung | Großartig | Korrekt (mod_ssl) |
| Statische Dateien | Sehr schnell (sendfile) | Richtig |
| Reverse-Proxy-App | Einheimisch, leicht | mod_proxy |
| URL-Umschreibung | try_files, Karten | .htaccess, mod_rewrite |
| PHP | Über PHP-FPM Upstream | PHP-FPM oder mod_php |
| Grundlegende Verzeichnisauthentifizierung | auth_basic | .htaccess AuthType |
Die nützliche Frage: Wie viel Datenverkehr erreicht den Webserver vor PHP – und wer sollte in der Lage sein, die Regeln zu ändern, ohne sie erneut bereitzustellen?
Konkrete Szenarien: drei typische Profile
Szenario A – SaaS PHP-FPM, API + SPA
Rund siebzig Prozent der Vermögenswerte laufen über ein CDN. Kein „.htaccess“-Client. Ratenbegrenzung und WebSocket-Proxy erforderlich. Nginx allein (oder Nginx + CDN) reicht aus; Apache bringt nichts Entscheidendes.
Szenario B – WordPress-Multi-Client-Shared-Hosting
„.htaccess“-Regeln pro Site, Plugins, die Rewrite-Regeln schreiben, historische mod_php-Unterstützung. Apache bleibt die natürliche Wahl – oder Nginx mit manueller Konvertierung von Regeln, was oft unterschätzte Migrationskosten verursacht.
Szenario C – Allmählicher Übergang
Legacy-Apache + neue Node-Anwendung. Nginx-Frontend → Apache (Port 8080) + Knoten (Port 3000) nach „Standort“-Block. Gemeinsame Architektur, wenn Sie nicht alles auf einmal migrieren können.
Leistung: Was Benchmarks vergessen
Nginx überzeugt gegenüber gleichzeitigen Verbindungen und statischen Dateien. Apache mit mpm_event + PHP-FPM bleibt für mäßig dynamisches PHP konkurrenzfähig. Der Flaschenhals liegt oft bei PHP und MySQL, nicht beim Webserver selbst.
Messung vor der Migration: TTFB-Ursprung mit und ohne Cache, Anteil der statischen 304/200-Antworten, die direkt von Nginx bereitgestellt werden, Speicherkosten von mod_php im Vergleich zu PHP-FPM. Ein Wechsel des Webservers ohne diese Zahlen bedeutet manchmal eine wochenlange Migration mit einem Gewinn von fünf Prozent – während ein fehlender SQL-Index fünfzig Prozent wert ist.
Shared Hosting, VPS oder PaaS
Bei shared werden häufig Apache und „.htaccess“ auferlegt; Nginx bleibt selten konfigurierbar. Auf VPS ist die Wahl frei: Nginx + PHP-FPM wird für ein neues Projekt ohne „.htaccess“-Schulden empfohlen. Bei PaaS verbirgt eine Abstraktionsschicht (Caddy, Traefik) den Webserver – Sie haben keine wirkliche Auswahl mehr.
Installieren Sie auf VPS nur ein Frontend, sofern keine dokumentierte Hybridarchitektur vorliegt – vermeiden Sie Nginx + Apache ohne Grund (doppelte TLS-Konfiguration, doppelte Fehleroberfläche).
Speziell für WordPress rundet der Vergleich Apache oder Nginx für WordPress diese Lektüre ab. Für einen leichteren Stack siehe auch Nginx ou Caddy.
Die Spitze: Reputation ersetzt selten das Abfrageinventar
Der Wechsel von Webservern ohne Profilierung bedeutet manchmal wöchentliche Migration für einen Gewinn von fünf Prozent – wohingegen ein Datenbankindex fünfzig Prozent wert ist.
Entscheide dich und gehe ohne blinden Fleck voran
An einem halben Tag können Sie ohne blinden Fleck entscheiden. Verfolgen Sie zehn typische Anfragen (Home, API, Admin, Asset). Listen Sie die erforderlichen „.htaccess“-Abhängigkeiten und Apache-Module auf. Messen Sie den TTFB, um zu prüfen, ob der Webserver tatsächlich der Flaschenhals ist. Wenn Sie sich für Nginx entscheiden, planen Sie die Regelkonvertierung und testen Sie 301-Weiterleitungen. Wenn Sie beides kombinieren, sollte Nginx nur als Proxy fungieren – als einzelner Eigentümer der Konfiguration.
Siehe Apache oder Nginx für WordPress und Nginx oder Caddy. Um das zugrunde liegende Hosting auszuwählen, durchsuchen Sie das Verzeichnis und den Vergleich.
Häufig gestellte Fragen
Ersetzt Nginx immer noch Apache?
Nein. Nginx ist im Frontend oft besser (TLS, Cache, Reverse-Proxy). Apache bleibt relevant, wenn Sie auf verzeichnisspezifische „.htaccess“, veraltete mod_php oder Module ohne Nginx-Äquivalent angewiesen sind. Die richtige Wahl lässt sich an Ihrem Stack ablesen, nicht an der Reputation des Logos.
Welche Kombination für modernes PHP?
Nginx + PHP-FPM ist der aktuelle Standard. Apache + PHP-FPM funktioniert auch. Vermeiden Sie mod_php in einer ausgelasteten Produktion: Arbeiter vermischen Weblast und PHP-Last, was die Dimensionierung erschwert.
Können wir beide verwenden?
Ja. Nginx als Reverse-Proxy vor Apache oder vor Node/Python-Anwendungen ist eine gängige Architektur bei der progressiven Migration. Wichtig ist, zu dokumentieren, wer TLS beendet und wo die Rewrite-Regeln gelten.
Wie entscheidet man sich in 30 Minuten?
Listen Sie den Prozentsatz des statischen Datenverkehrs, die „.htaccess“-Anforderung, die erforderlichen Module und die Teamfähigkeit auf. Wenn achtzig Prozent statisch/CDN + PHP-FPM → Nginx-Frontend. Wenn Dutzende von „.htaccess“-Regeln Client → Apache- oder Nginx-Migrationsbudget.
Nginx oder Apache wird im Anforderungspfad ausgewählt – nicht im Logo der Folienarchitektur.