Nginx vs. Apache: Welcher Webserver passt?

Nginx und Apache sind beide belastbare Webserver, unterscheiden sich aber bei Prozessmodell, Konfigurationsdelegation und Erweiterbarkeit. Nginx passt oft als zentral verwalteter Reverse Proxy; Apache bleibt stark, wenn Anwendungen Module oder verzeichnisweise Regeln erwarten. Entscheidend sind deshalb Anwendungspfad, Betriebsmodell und ein eigener Lasttest statt pauschaler Siegerlisten.

Die kurze Entscheidung

Wer nur nach einem Sieger sucht, stellt die falsche Frage. Nginx ist keine automatische Performance-Garantie, und Apache ist nicht grundsätzlich schwerfällig. Beide können statische Dateien ausliefern und als Reverse Proxy arbeiten. Für den Betrieb zählt, wie sie Verbindungen bearbeiten, Konfiguration verteilen und Anwendungskompatibilität herstellen.

Für eine zentral betriebene Plattform mit mehreren Diensten ist Nginx häufig ein klarer Einstiegspunkt. Seine Konfiguration bündelt Routing, TLS-Terminierung und Weiterleitung an Upstreams an einer kontrollierten Stelle. Apache ist oft die passendere Wahl, wenn eine Anwendung Apache-Module voraussetzt, vorhandene verzeichnisbezogene Regeln weiterleben müssen oder Betreiber Konfigurationsrechte bewusst an einzelne Verzeichnisse delegieren.

Eine Kombination kann sinnvoll sein: Nginx nimmt externe Verbindungen an und leitet dynamische Anfragen an Apache weiter. Sie ist aber kein kostenloser Gewinn. Ein zusätzlicher Webserver bedeutet einen weiteren Konfigurationsstand, zusätzliche Logs und eine weitere Fehlergrenze. Betrieb schlägt Prospekt: Zwei Schichten brauchen einen nachweisbaren Grund.

Architektur ohne den üblichen Mythos

Nginx startet einen Master-Prozess und mehrere Worker-Prozesse. Die Worker bearbeiten Anfragen ereignisbasiert und nutzen dafür Mechanismen des Betriebssystems. Das Modell eignet sich gut für viele gleichzeitig offene Verbindungen, sagt allein aber noch nichts darüber aus, wie schnell die gesamte Anwendung antwortet. Datenbank, Anwendungscode, Speicher, Netzwerk und Caching bleiben Teil des Pfads.

Bei Apache bestimmt ein Multi-Processing Module, kurz MPM, das Prozess- und Thread-Modell. Ein Server verwendet jeweils genau ein MPM. Event, Worker und Prefork haben unterschiedliche Eigenschaften. Deshalb ist die verbreitete Aussage, Apache starte pauschal für jede Verbindung einen eigenen Prozess, zu grob. Das Event-MPM kann Threads von Teilen der Verbindungsverwaltung entlasten; Prefork arbeitet dagegen ohne Threads und bleibt für bestimmte Kompatibilitätsanforderungen relevant.

Vergleichen Sie also nicht Nginx mit einem erfundenen Einheits-Apache. Prüfen Sie, welches Apache-MPM tatsächlich läuft, welche Module geladen sind und wie die Anwendung angebunden ist. Ein Benchmark mit unbekannter MPM-Konfiguration beantwortet keine Betriebsfrage.

Konfiguration: zentral oder delegiert

Der praktisch größte Unterschied ist häufig nicht Geschwindigkeit, sondern Hoheit. Nginx arbeitet mit zentraler Konfiguration. Änderungen werden geprüft und anschließend neu geladen. Scheitert die Prüfung oder kann die neue Konfiguration nicht angewendet werden, bleibt die bisherige Konfiguration bestehen. Bei erfolgreichem Reload starten neue Worker mit dem neuen Stand, während alte Worker ihre Arbeit kontrolliert beenden.

Apache kann ebenfalls kontrolliert neu gestartet oder beendet werden. Zusätzlich unterstützt er .htaccess-Dateien, sofern der Administrator dies über AllowOverride erlaubt. Damit können Regeln in einzelnen Verzeichnissen liegen. Das ist nützlich, wenn Nutzer oder Anwendungen keinen Zugriff auf die Hauptkonfiguration erhalten sollen. Es erweitert aber zugleich die Konfigurationsfläche: Der Server muss nach solchen Dateien suchen, und eine delegierte Regel kann Sicherheit, Routing oder Zugriffsschutz beeinflussen.

Die Apache-Dokumentation empfiehlt die Hauptkonfiguration, wenn Administratoren darauf zugreifen können. Das ist eine gute betriebliche Leitplanke. Verzeichnisweise Konfiguration ist ein Delegationswerkzeug, kein Qualitätsmerkmal an sich. Fragen Sie, wer Regeln ändern darf, wie Änderungen geprüft werden und wie ein fehlerhafter Stand zurückgenommen wird.

Bei Migrationen ist dieser Punkt entscheidend. Eine Anwendung mit gewachsenen Rewrite- und Zugriffsregeln zieht nicht durch bloßes Kopieren des Document Root um. Vor einem Wechsel zu Nginx müssen die Regeln inventarisiert, übersetzt und getestet werden. Wer diesen Aufwand übersieht, verschiebt das Risiko in den ersten Produktionsaufruf.

Reverse Proxy und dynamische Anwendungen

Nginx kann statische Inhalte direkt ausliefern und Anfragen an Anwendungsserver weiterleiten. Für mehrere Upstreams stehen unterschiedliche Verteilungsverfahren zur Verfügung. Welche Instanz ausgewählt wird und wie Fehler behandelt werden, hängt von der konkreten Konfiguration ab. Der Name des Webservers ersetzt weder Health Checks noch Timeouts, Retry-Regeln oder eine saubere Beobachtung des Upstream-Pfads.

Apache kann mit mod_proxy ebenfalls als Reverse Proxy arbeiten. Je nach Zielprotokoll und gewünschter Lastverteilung kommen weitere Module hinzu. Damit ist die Behauptung falsch, nur Nginx eigne sich als Proxy. Die sinnvollere Frage lautet: Welches Team kann den gesamten Anfragepfad unter Last erklären und im Fehlerfall bedienen?

Bei PHP, Python, Ruby, Node.js oder anderen Laufzeiten entsteht ein großer Teil der Antwortzeit hinter dem Webserver. Ein schneller statischer Test kann deshalb wenig über eine reale Anwendung aussagen. Prüfen Sie mindestens:

• den Anteil statischer und dynamischer Antworten;
• die Zahl gleichzeitig offener, langsamer Verbindungen;
• Antwortzeiten und Fehler im Anwendungs-Upstream;
• Speicherverbrauch und Warteschlangen bei reproduzierbarer Last;
• Verhalten bei Reload, Ausfall eines Upstreams und Wiederanlauf.

Der Test muss die eigene Anwendung, typische Dateigrößen, TLS und realistische Cache-Zustände abbilden. Ein fremder Balken mit Anfragen pro Sekunde verschweigt meist genau die Randbedingungen, die später den Betrieb bestimmen.

Wann Nginx die klarere Wahl ist

Nginx passt häufig, wenn das Team einen zentralen Einstiegspunkt vor mehreren Diensten betreibt. Routing und Proxy-Regeln liegen an einer Stelle, statische Dateien lassen sich dort ausliefern, und neue Konfigurationen können vor dem Reload geprüft werden. Das macht die Verantwortung sichtbar.

Gute Signale für Nginx sind:

• mehrere Anwendungsdienste hinter einer gemeinsamen Edge-Schicht;
• zentrale Verantwortung für TLS, Weiterleitung und Zugriffskontrolle;
• viele gleichzeitig offene Verbindungen als gemessener Teil der Last;
• keine Abhängigkeit von .htaccess oder Apache-spezifischen Modulen;
• ein Team, das Upstream-Timeouts, Logs und Reloads aktiv betreibt.

Nginx ist weniger passend, wenn eine Anwendung ihre Betriebsregeln ausschließlich als .htaccess mitbringt und niemand die Übersetzung verantwortet. Auch ein kleines, stabiles Apache-System wird nicht allein dadurch besser, dass ein weiterer Proxy davorsteht.

Wann Apache die klarere Wahl ist

Apache passt, wenn Kompatibilität und kontrollierte Delegation den Ausschlag geben. Bestehende Anwendungen können auf bestimmte Module, Authentifizierungswege oder verzeichnisbezogene Regeln angewiesen sein. In solchen Fällen ist der geringere Migrationsaufwand ein echter Betriebswert.

Gute Signale für Apache sind:

• eine belegte Abhängigkeit von Apache-Modulen oder vorhandenen Regeln;
• bewusst delegierte Konfiguration in getrennten Verzeichnissen;
• ein passendes, verstandenes MPM für die Anwendung;
• etablierte Verfahren für Graceful Restart, Logs und Rücknahme;
• ein Team, das Modulbestand und AllowOverride-Grenzen regelmäßig prüft.

Apache ist weniger passend, wenn niemand weiß, welches MPM läuft, welche Module geladen sind oder wo .htaccess-Dateien Regeln überschreiben. Flexibilität ohne Inventar ist keine Stärke. Fragen Sie nach dem Ausfallpfad: Wer erkennt eine fehlerhafte Regel, wer nimmt sie zurück, und wie lange bleiben Anfragen beeinträchtigt?

Beide zusammen: nur mit sauberer Grenze

Die Kombination Nginx vor Apache kann eine Migration erleichtern oder Verantwortungen trennen. Nginx übernimmt dann etwa den externen Einstieg, Apache bedient eine kompatibilitätskritische Anwendung. Tragfähig wird das erst mit einer eindeutigen Grenze.

Klären Sie vorher, welcher Server TLS beendet, echte Client-Adressen weitergibt, Redirects setzt, Kompression steuert und Fehlerseiten liefert. Doppelte Regeln führen zu Schleifen, widersprüchlichem Caching oder schwer lesbaren Logs. Auch Timeouts müssen zusammenpassen: Ein vorgeschalteter Proxy darf die Verbindung nicht abbrechen, während der dahinterliegende Server noch regulär arbeitet.

Reaktionszeit zählt in Minuten. Für Störungen braucht das Team einen Ablauf, der den fehlerhaften Abschnitt schnell eingrenzt. Wenn jede Schicht eigene Kennzahlen und Zeitstempel liefert, lässt sich der Pfad verfolgen. Fehlt diese Zuordnung, verdoppelt eine zweite Schicht vor allem die Suchfläche.

Entscheidung in einem Wartungsfenster vorbereiten

Beginnen Sie nicht mit einer Neuinstallation, sondern mit einem Inventar. Notieren Sie Anwendungslaufzeit, aktuelle Module, MPM, verzeichnisbezogene Regeln, Proxy-Ziele, TLS-Verantwortung und den Reload-Ablauf. Danach bauen Sie denselben repräsentativen Pfad in einer isolierten Umgebung auf.

Messen Sie nicht nur Durchsatz. Beobachten Sie Antwortzeitverteilung, Fehler, Speicher, offene Verbindungen und das Verhalten bei einer Konfigurationsänderung. Simulieren Sie außerdem einen ausgefallenen Upstream. Der richtige Webserver ist derjenige, dessen Fehlerbild das Team versteht und dessen Rückweg geübt ist.

Fazit

Nginx ist oft der geradlinige zentrale Proxy; Apache ist oft der sichere Anschluss für modul- oder verzeichnisabhängige Anwendungen. Beide können mehr als ihr jeweiliges Klischee. Eine belastbare Wahl entsteht aus der tatsächlichen Konfiguration, einem repräsentativen Anwendungstest und einem geübten Reload- und Ausfallpfad.

Wer bereits Apache zuverlässig betreibt, braucht keinen Wechsel aus Prinzip. Wer Nginx vor mehrere Dienste setzt, sollte die neue Schicht als eigenes Betriebsmittel behandeln. Und wer beide kombiniert, dokumentiert die Grenze so genau wie einen Bremsweg: Last, Reaktion und Reserve müssen bekannt sein, bevor es eng wird.