Apache vs Nginx – diese Frage stellt sich jeder, der zum ersten Mal einen eigenen Server aufsetzt, und überraschend viele, die es schon hundertmal getan haben. Die kurze Antwort: Beide sind exzellente Webserver, beide betreiben zusammen über die Hälfte des Internets, und in 90 Prozent der Fälle ist die Architektur deines Setups wichtiger als die Wahl des Servers. Die längere Antwort – und die ist es wert – erklärt dir, warum die beiden so unterschiedlich ticken, wo die Unterschiede wirklich Geld und Nerven kosten und welche Wahl für dein konkretes Projekt die richtige ist.
Wir betreiben seit Jahren produktive Server mit beiden Systemen (und inzwischen auch mit Caddy, dazu am Ende mehr) – von kleinen WordPress-Instanzen über Shopware-Shops bis zu Node.js-Anwendungen hinter Reverse Proxies. Dieser Vergleich kommt also nicht aus dem Benchmark-Labor, sondern aus dem Alltag, in dem um 3 Uhr nachts ein Server brennt und du wissen musst, wo die Config liegt.
Apache vs Nginx: Die kurze Antwort vorweg
Falls du nur eine Entscheidung brauchst und keinen Deep Dive:
- Shared Hosting, WordPress mit vielen Plugins, .htaccess-Abhängigkeit: Apache
- Hoher Traffic, statische Inhalte, Reverse Proxy, Microservices: Nginx
- Moderne Container-Setups, APIs, Single-Page-Apps: Nginx
- Du erbst ein Legacy-System: Lass laufen, was läuft – Migration nur mit gutem Grund
- Neues Projekt auf eigenem Server und du willst es einfach: Schau dir zusätzlich Caddy an
Marktanteile zur Einordnung (W3Techs, Stand 2026): Nginx liegt bei rund 33 Prozent der bekannten Webserver, Apache bei etwa 24 Prozent. Vor zehn Jahren war das Verhältnis noch umgekehrt. Der Trend ist eindeutig – aber Marktanteil allein ist kein Argument, sonst würden wir alle nur noch WordPress benutzen.
Die Geschichte: Warum es überhaupt zwei gibt
Apache HTTP Server erschien 1995 und war über 15 Jahre lang der Webserver schlechthin. Der Name stammt angeblich von “a patchy server” – ein zusammengeflickter Nachfolger des NCSA-Servers. Apache hat das Web großgezogen: Ohne ihn kein LAMP-Stack (Linux, Apache, MySQL, PHP), ohne LAMP kein WordPress, kein frühes Facebook, keine Shared-Hosting-Industrie.
Nginx (gesprochen “Engine-X”) wurde 2004 vom russischen Entwickler Igor Sysoev veröffentlicht – als direkte Antwort auf das sogenannte C10k-Problem: die Frage, wie ein Server 10.000 gleichzeitige Verbindungen verarbeiten kann, ohne zusammenzubrechen. Apache konnte das damals nicht, denn seine Architektur bindet pro Verbindung einen Prozess oder Thread. Sysoev baute deshalb einen Server mit komplett anderem Fundament: ereignisgesteuert, asynchron, minimaler Speicherverbrauch.
Diese beiden Geburtsstunden erklären bis heute fast alle Unterschiede: Apache wurde für maximale Flexibilität in einer Welt aus Shared Hosting und PHP gebaut. Nginx wurde für maximale Effizienz in einer Welt aus hohem Traffic und Proxying gebaut.
Architektur: Der fundamentale Unterschied
Hier liegt der Kern des Vergleichs Apache vs Nginx – alles andere folgt daraus.
Apache: Prozesse und Threads
Apache arbeitet mit sogenannten MPMs (Multi-Processing Modules), die bestimmen, wie Anfragen verarbeitet werden:
- prefork: Ein Prozess pro Verbindung. Robust, aber speicherhungrig – jeder Prozess belegt schnell 20 bis 50 MB RAM. Bei 500 gleichzeitigen Verbindungen bist du bei 10 bis 25 GB. Autsch.
- worker: Mehrere Threads pro Prozess – deutlich effizienter, aber Threads teilen sich Speicher, was mit nicht-threadsicheren Modulen (klassisch: mod_php) Probleme macht.
- event: Der modernste MPM, seit Apache 2.4 stabil. Er entkoppelt Keep-Alive-Verbindungen von Worker-Threads und nähert sich damit dem Nginx-Modell an.
Das Entscheidende: Selbst mit dem event-MPM bleibt Apaches Grundmodell “ein Worker kümmert sich um eine aktive Anfrage”. Unter Last skaliert das linear mit dem Speicher – und irgendwann ist der voll.
Nginx: Der Event-Loop
Nginx startet eine kleine, feste Anzahl von Worker-Prozessen (typisch: einer pro CPU-Kern). Jeder Worker verarbeitet tausende Verbindungen gleichzeitig in einer Ereignisschleife: Statt auf langsame Clients zu warten, springt der Worker einfach zur nächsten Verbindung, bei der etwas zu tun ist. Kein Warten, kein Speicher-Overhead pro Verbindung, keine Thread-Verwaltung.
Das Resultat in der Praxis: Ein Nginx mit 512 MB RAM hält problemlos zehntausende Keep-Alive-Verbindungen offen, wo ein Apache mit prefork längst im Swap steht. Genau deshalb wurde Nginx zum Standard für alles, was viele gleichzeitige Verbindungen bedeutet: Load Balancer, Reverse Proxies, Streaming, APIs mit langlebigen Connections.
Wichtig für die Fairness: Für dynamische Inhalte (PHP, Python, Node.js) müssen beide Server die Arbeit sowieso an externe Prozesse weiterreichen – PHP-FPM, Gunicorn, Node-Server. Bei einer typischen WordPress-Seite verbringt der Webserver die meiste Zeit mit Warten auf PHP und die Datenbank. Der Architekturvorteil von Nginx spielt seine Stärke deshalb vor allem bei statischen Dateien und vielen parallelen Verbindungen aus – nicht bei der einzelnen dynamischen Anfrage.
Performance: Was Benchmarks sagen – und was sie verschweigen
Die Benchmark-Wahrheit zuerst: Bei statischen Dateien ist Nginx typischerweise zwei- bis viermal schneller als ein unoptimierter Apache und verbraucht dabei einen Bruchteil des Speichers. Bei tausenden gleichzeitigen Verbindungen wächst der Abstand weiter, weil Apache-Worker knapp werden, während der Nginx-Event-Loop unbeeindruckt weiterläuft.
Aber jetzt die Praxis-Wahrheit, die in Benchmark-Artikeln gern fehlt:
1. Deine Seite ist wahrscheinlich nicht statisch. Bei PHP-Anwendungen (WordPress, Shopware, Laravel) hängt die Antwortzeit zu 90 Prozent an PHP-FPM, Datenbank und Caching – nicht am Webserver. Apache mit event-MPM und PHP-FPM ist für die allermeisten Projekte schnell genug. Wer WordPress beschleunigen will, sollte zuerst über Page-Caching und OPcache reden, nicht über Apache vs Nginx.
2. Der Unterschied zeigt sich unter Last. Bei 50 Besuchern gleichzeitig merkst du nichts. Bei 5.000 merkst du alles. Die Frage ist nicht “welcher Server ist schneller”, sondern “erreiche ich die Region, in der es zählt”. Ein kleiner Firmen-Blog erreicht sie nie. Ein Shop am Black Friday sehr wohl.
3. RAM ist das eigentliche Argument. Auf einem kleinen VPS mit 2 GB RAM ist der Speicherverbrauch wichtiger als die reine Geschwindigkeit. Nginx lässt schlicht mehr Luft für PHP-FPM und die Datenbank – und genau daran hängt die gefühlte Performance.
Unsere Faustregel: Performance ist ein valides Argument für Nginx, aber erst ab nennenswertem Traffic oder knappem RAM. Darunter entscheidet der Komfort.
Konfiguration: .htaccess vs zentrale Config
Hier trennen sich die Philosophien am deutlichsten – und hier entstehen im Alltag die meisten Gefühle.
Apache: Flexibilität durch .htaccess
Apaches berühmtestes Feature ist die .htaccess-Datei: Konfiguration auf Verzeichnisebene, änderbar ohne Root-Rechte, ohne Neustart, wirksam ab der nächsten Anfrage. Darauf baut die halbe Hosting-Industrie auf – jeder Shared Hoster erlaubt seinen Kunden, per .htaccess Redirects, Rewrites und Passwortschutz einzurichten, ohne den Server anfassen zu können. Auch WordPress-Plugins schreiben munter Rewrite-Regeln in die .htaccess, und alles funktioniert einfach.
Der Preis: Performance und Übersicht. Apache muss bei jeder Anfrage den kompletten Verzeichnispfad nach .htaccess-Dateien absuchen und sie parsen – bei tiefen Verzeichnisstrukturen ein messbarer Overhead. Und nach fünf Jahren Projektgeschichte weiß niemand mehr, welche der sieben .htaccess-Dateien im Baum welche Regel überschreibt.
Nginx: Ein Ort für alles
Nginx kennt kein .htaccess. Die gesamte Konfiguration liegt zentral (typisch unter /etc/nginx/), Änderungen erfordern ein Reload. Die Syntax ist deklarativ und deutlich lesbarer:
server {
listen 443 ssl http2;
server_name example.com;
root /var/www/example;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}Wer von Apache kommt, vermisst anfangs die Freiheit. Wer sich eingearbeitet hat, will meist nie zurück: Eine Datei, eine Wahrheit, ein nginx -t zum Validieren vor dem Reload. Für Teams und Automatisierung (Ansible, Docker, CI/CD) ist das zentrale Modell schlicht wartbarer.
Der ehrliche Nachteil: Ohne Root-Zugriff keine Konfigurationsänderung. Für Shared Hosting ist Nginx deshalb als Kunden-Webserver praktisch ungeeignet – was erklärt, warum Apache dort weiterhin dominiert.
Reverse Proxy: Die Paradedisziplin von Nginx
Moderne Web-Architekturen bestehen selten aus einem einzelnen Server, der PHP-Dateien ausliefert. Stattdessen: eine Node.js-API hier, ein Python-Backend da, ein statisches Frontend, alles hinter einem zentralen Einstiegspunkt. Dieser Einstiegspunkt – der Reverse Proxy – nimmt alle Anfragen entgegen, terminiert TLS, verteilt auf Backends, cached Antworten und schützt die dahinterliegenden Dienste.
Genau dafür wurde Nginx gebaut, und es zeigt sich in jedem Detail:
upstream app_backend {
least_conn;
server 127.0.0.1:3000;
server 127.0.0.1:3001;
}
server {
listen 443 ssl http2;
server_name app.example.com;
location / {
proxy_pass http://app_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Zehn Zeilen, und du hast Load Balancing mit Health-Verhalten, Header-Weiterleitung und HTTP/2. Nginx als Reverse Proxy vor Anwendungsservern ist so etabliert, dass es selbst dann eingesetzt wird, wenn Apache die Anwendung ausliefert – Nginx vorn für TLS und statische Dateien, Apache hinten für die .htaccess-abhängige Applikation. Dieses Sandwich-Setup war jahrelang der Standard-Kompromiss der Hosting-Welt.
Apache kann Reverse Proxying (mod_proxy, mod_proxy_balancer) und macht es ordentlich. Aber die Konfiguration ist geschwätziger, der Speicherverbrauch pro Verbindung höher, und bei WebSockets oder langlebigen Verbindungen merkt man, dass es nicht die Kernaufgabe ist. Wer heute einen dedizierten Proxy oder Load Balancer aufsetzt, greift in der Praxis zu Nginx, HAProxy, Traefik oder Caddy – fast nie zu Apache.
Module, Ökosystem und Dynamik
Apache lädt Module dynamisch zur Laufzeit: a2enmod rewrite, Reload, fertig. Das Ökosystem ist riesig und deckt nach 30 Jahren jeden erdenklichen Fall ab – von mod_security (Web Application Firewall) über mod_auth_kerb bis zu Exoten, die sonst niemand braucht. Diese Flexibilität ohne Neukompilieren ist ein echter Apache-Vorteil.
Nginx kompilierte Module historisch fest ein – inzwischen gibt es dynamische Module, aber das Ökosystem funktioniert anders: Viele Erweiterungen, die bei Apache ein Modul wären, sind bei Nginx entweder eingebaut, werden über die Config gelöst oder laufen als separater Dienst dahinter. Für exotischere Anforderungen gibt es OpenResty – Nginx mit eingebettetem Lua, quasi ein programmierbarer Webserver – und kommerzielle Features in Nginx Plus.
Ein Wort zu HTTP/2 und HTTP/3: HTTP/2 beherrschen beide seit Jahren stabil. Bei HTTP/3 (QUIC) ist Nginx seit Version 1.25 mit offizieller Unterstützung dabei, während Apache hier bis heute hinterherhängt – wer das neueste Protokoll für mobile Nutzer will (spürbar bei schlechten Verbindungen), findet bei Nginx oder Caddy die reifere Umsetzung.
In der Praxis ist der Modul-Punkt heute weniger wichtig als vor zehn Jahren: TLS, HTTP/2, Kompression, Rate Limiting, Caching und Proxying können beide von Haus aus. Relevant wird er, wenn du sehr spezielle Anforderungen hast – dann lohnt ein konkreter Blick, wer dein Feature eleganter abdeckt.
Sicherheit und Betrieb im Alltag
Beide Server sind bei sauberer Konfiguration sicher, beide bekommen zeitnah Patches, beide haben nach Jahrzehnten im Feuer eine solide Security-Historie. Die Unterschiede liegen im Drumherum:
- Angriffsfläche: Nginx’ schlankerer Kern und das zentrale Config-Modell bedeuten weniger Stellen, an denen sich Fehlkonfiguration verstecken kann. Apaches .htaccess-Mechanik ist ein klassisches Einfallstor für vergessene Altlasten – irgendwo liegt immer noch eine Regel von 2019.
- DDoS und Slow-Attacks: Angriffe wie Slowloris, die Verbindungen absichtlich offen halten, treffen das Prozessmodell von Apache härter (Worker-Auslastung) als den Event-Loop von Nginx. Mit dem event-MPM und mod_reqtimeout ist Apache heute deutlich robuster als früher, aber die Architektur von Nginx ist hier von Natur aus im Vorteil.
- Rate Limiting: In Nginx mit zwei Zeilen Config erledigt (
limit_req_zone), bei Apache über mod_ratelimit/mod_qos etwas hakeliger. - Logs und Debugging: Geschmackssache. Apaches Fehlermeldungen sind oft gesprächiger, Nginx’ Logs strukturierter. Beide lassen sich sauber an fail2ban, Prometheus und Co. anbinden.
Ein Betriebsaspekt, der unterschätzt wird: Konfigurationsfehler. nginx -t prüft die komplette Config vor dem Reload – ein kaputtes Deployment fällt sofort auf. Apache hat mit apachectl configtest ein Äquivalent, aber .htaccess-Dateien werden dabei nicht geprüft: Ein Tippfehler dort wirft im laufenden Betrieb 500er-Fehler, ohne dass ein Test ihn vorher fängt. Dieses Detail hat schon vielen Admins den Abend versaut.
Wann Apache, wann Nginx? Konkrete Szenarien
Genug Theorie – hier die Entscheidungen, wie wir sie treffen würden:
WordPress auf Shared Hosting: Keine echte Wahl – du bekommst, was der Hoster gibt, meist Apache oder LiteSpeed. Völlig okay.
WordPress/WooCommerce auf eigenem VPS: Nginx + PHP-FPM + Page Cache. Die .htaccess-Regeln der üblichen Plugins lassen sich fast immer in wenige Zeilen Nginx-Config übersetzen (die Suchmaschine deines Vertrauens kennt jede Übersetzung). Der RAM-Gewinn auf kleinen Servern ist es wert.
Shopware / Magento / große PHP-Shops: Nginx ist bei beiden der dokumentierte Standard-Stack. Hier gibt es wenig zu diskutieren – die offiziellen Deployment-Guides gehen von Nginx aus, und unter Last (Sale-Aktionen!) zählt jede Verbindung.
Node.js / Python / Go-Anwendungen: Nginx als Reverse Proxy davor, fertig. Die Anwendung spricht HTTP auf localhost, Nginx übernimmt TLS, statische Dateien, Kompression und Pufferung.
Intranet-Anwendungen mit LDAP/Kerberos-Auth und komplexen Auth-Ketten: Apache. Das Auth-Modul-Ökosystem ist hier schlicht reifer.
Legacy-Anwendung, die tief mit .htaccess verwachsen ist: Apache behalten – oder das Sandwich (Nginx vorn, Apache hinten), wenn TLS-Handling und statische Auslieferung modernisiert werden sollen, ohne die Anwendung anzufassen.
Docker/Kubernetes: Nginx dominiert als Ingress und als schlanker Static-File-Container. Apache-Images existieren, sind aber die Ausnahme geworden.
Migration: Von Apache zu Nginx wechseln – lohnt sich das?
Die Frage kommt in jedem zweiten Beratungsgespräch: “Sollten wir auf Nginx migrieren?” Unsere Gegenfragen: Hast du RAM-Probleme? Brichst du unter Last ein? Baust du deine Architektur sowieso um (Container, neuer Server, neues Deployment)? Wenn dreimal nein – lass es. Eine Migration ohne Leidensdruck ist Risiko ohne Rendite.
Wenn du migrierst, sind das die Stolpersteine aus der Praxis:
1. .htaccess-Regeln übersetzen. Der größte Brocken. Rewrites, Redirects und Auth-Regeln müssen in die zentrale Nginx-Config wandern. Für Standard-Fälle (WordPress-Permalinks, Trailing Slashes, www-Redirects) gibt es erprobte Vorlagen; für gewachsene Regelwälder brauchst du eine Inventur: Welche Regeln sind überhaupt noch aktiv? Erfahrungsgemäß sind 30 bis 50 Prozent tot.
2. PHP-Anbindung umstellen. Wer noch mod_php nutzt, wechselt auf PHP-FPM – was ohnehin überfällig ist, auch unter Apache. FPM-Pools richtig dimensionieren (pm.max_children an RAM und Prozessgröße ausrichten!), sonst tauschst du ein Speicherproblem gegen ein anderes.
3. Parallel testen, dann umschalten. Nginx auf einem anderen Port hochziehen, mit curl und echten URLs durchtesten (Statuscodes! Redirects! Headers!), dann DNS oder Proxy umschwenken. Nie über Nacht “einfach umstellen” – der Klassiker endet mit kaputten Deep-Links, die erst nach Wochen auffallen, wenn die Rankings weg sind.
4. Monitoring nicht vergessen. Access-Log-Formate unterscheiden sich; wer Auswertungen oder fail2ban-Regeln auf Apache-Formate gebaut hat, zieht sie nach.
Realistischer Aufwand für eine typische PHP-Anwendung: ein bis drei Tage inklusive Tests – nicht die Wochen, vor denen manche Agentur warnt, aber auch kein Nachmittagsprojekt.
Der lachende Dritte: Caddy (und die ehrliche Meta-Frage)
Ein Vergleich Apache vs Nginx wäre 2026 unvollständig ohne den Hinweis, dass die Frage selbst an Bedeutung verliert. Caddy – der Webserver, mit dem unter anderem diese Seite ausgeliefert wird – macht vieles von beidem überflüssig einfach: automatisches HTTPS mit Let’s-Encrypt-Zertifikaten ohne eine Zeile Konfiguration, HTTP/3 ab Werk, eine Config-Datei, die man ohne Doku lesen kann. Für kleine bis mittlere Projekte auf eigenem Server ist Caddy inzwischen unsere Standard-Empfehlung – der Komfortgewinn ist enorm.
Warum trotzdem Apache und Nginx lernen? Weil sie der Industriestandard sind. Jeder Hoster, jedes Tutorial, jede Stack-Dokumentation, jeder DevOps-Job setzt eines von beiden voraus. Caddy ist die bequeme Wahl fürs eigene Projekt; Apache- und Nginx-Kenntnisse sind die Währung, mit der du im Beruf bezahlst.
Fazit: Apache vs Nginx – unsere Empfehlung
Die Architektur erzählt die ganze Geschichte: Apache wurde für Flexibilität gebaut, Nginx für Effizienz. Daraus folgt fast alles – .htaccess vs zentrale Config, Speicherverbrauch vs Modul-Vielfalt, Shared-Hosting-Dominanz vs Proxy-Dominanz.
Für neue Projekte auf eigener Infrastruktur ist Nginx in den meisten Fällen die bessere Wahl: effizienter, wartbarer, der De-facto-Standard moderner Stacks. Apache bleibt die richtige Wahl, wo .htaccess gebraucht wird, wo sein Auth- und Modul-Ökosystem punktet und wo es schlicht schon läuft – ein funktionierendes Apache-Setup umzuziehen, nur weil Benchmarks hübscher aussehen, ist verschwendete Lebenszeit.
Und die wichtigste Erkenntnis aus Jahren Server-Praxis: Ein gut konfigurierter Apache schlägt einen schlecht konfigurierten Nginx jederzeit – und umgekehrt. Caching-Strategie, PHP-FPM-Tuning, Datenbank-Indizes und ein CDN bringen bei fast jedem Projekt mehr als der Webserver-Wechsel. Wähl den Server, den du verstehst und wartest, nicht den mit dem besten Benchmark-Balken.
Häufige Fragen zu Apache vs Nginx (FAQ)
Ist Nginx wirklich schneller als Apache? Bei statischen Dateien und vielen gleichzeitigen Verbindungen: ja, deutlich – typisch Faktor zwei bis vier bei drastisch geringerem Speicherverbrauch. Bei dynamischen Anwendungen (PHP & Co.) schrumpft der Unterschied auf wenige Prozent, weil die Zeit in PHP-FPM und der Datenbank verbracht wird.
Kann ich Apache und Nginx gleichzeitig nutzen? Ja – das klassische Sandwich: Nginx vorn als Reverse Proxy (TLS, statische Dateien, Caching), Apache dahinter für die Anwendung mit ihren .htaccess-Regeln. Jahrelang der Standard-Kompromiss, heute meist nur noch für Legacy-Setups sinnvoll.
Was nutzt WordPress – Apache oder Nginx? WordPress läuft auf beiden hervorragend. Shared Hosting liefert meist Apache oder LiteSpeed; die großen Managed-WordPress-Hoster setzen fast alle auf Nginx. Die offizielle wordpress.org-Doku behandelt beide als gleichwertig.
Ist Nginx schwerer zu lernen? Anders, nicht schwerer. Wer .htaccess gewohnt ist, braucht eine Umgewöhnungsphase auf zentrale Configs. Die Nginx-Syntax selbst ist logischer und besser lesbar als Apaches Direktiven-Mix.
Was ist mit LiteSpeed? LiteSpeed (bzw. das kostenlose OpenLiteSpeed) ist .htaccess-kompatibel bei Nginx-ähnlicher Performance und im WordPress-Shared-Hosting stark verbreitet. Für eigene Server bleibt es Nische – die Community und Doku von Nginx sind um Größenordnungen größer.
Apache vs Nginx für einen Reverse Proxy – gibt es Gründe für Apache? Wenige. Für reines Proxying/Load Balancing ist Nginx (oder HAProxy/Traefik/Caddy) die bessere Wahl. Apache als Proxy ergibt Sinn, wenn er sowieso läuft und die Anforderungen klein sind.
Mehr aus der Server-Praxis: In „Server gekapert: 5 Tage Albtraum” erzählen wir, was passiert, wenn Server-Sicherheit schiefgeht – und in unserem Shopware-Kosten-Guide spielt das Nginx-Setup eine Nebenrolle bei den Hosting-Kosten.