Apache vs. nginx vs. HAProxy¶
Siehe auch
- Verwandte Artikel
- Offizielle Dokumentation
- Linuxfabrik
Apache httpd, nginx und HAProxy decken drei unterschiedliche Aufgaben ab, die sich überschneiden, aber nicht deckungsgleich sind. Apache ist ein vollwertiger Webserver, der Inhalte ausliefert und über das mitgelieferte mod_proxy auch als Reverse Proxy arbeitet. nginx ist Webserver und ein starker Reverse Proxy mit Cache in einem. HAProxy ist ein spezialisierter Reverse Proxy und Load Balancer ohne eigene Inhaltsauslieferung.
Die Frage lautet darum selten „welches der drei“, sondern „welche Aufgabe“. Alle Angaben beziehen sich auf RHEL 10.
Begriffe¶
- Forward Proxy
Vermittelt ausgehende Anfragen von Clients ins Internet und tritt nach aussen an deren Stelle.
- Load Balancer
Verteilt Anfragen auf mehrere gleichartige Backends und prüft deren Gesundheit. Ziel sind Lastverteilung und Ausfallsicherheit.
- Reverse Proxy
Nimmt Anfragen aus dem Internet entgegen und reicht sie an interne Backends weiter. Übernimmt typischerweise TLS-Terminierung, Caching und Lastverteilung.
- Web Application Firewall (WAF)
Filtert HTTP-Anfragen anhand von Regeln und blockt bekannte Angriffsmuster wie SQL-Injection oder Cross-Site-Scripting.
- Worker-Modell
Art, wie ein Dienst Verbindungen verarbeitet: pro Verbindung ein Prozess oder Thread (speicherintensiv) gegenüber ereignisgesteuert (wenige Prozesse halten tausende Verbindungen).
Überblick¶
Kriterium |
Apache httpd |
nginx |
HAProxy |
|---|---|---|---|
Kommerzielle Variante |
nein |
nginx Plus (F5) |
HAProxy Enterprise, ALOHA |
Primärer Zweck |
Webserver, Reverse Proxy |
Webserver, Reverse Proxy |
Reverse Proxy, Load Balancer |
Statische Inhalte ausliefern |
ja |
ja, sehr schnell |
nein |
Dynamische Inhalte (PHP, WSGI) |
ja (PHP-FPM, FastCGI) |
ja (FastCGI, uwsgi) |
nein |
Reverse Proxy |
ja ( |
ja |
ja |
Forward Proxy |
ja ( |
nein |
nein |
Load Balancing |
byrequests, bytraffic, bybusyness, heartbeat ( |
round-robin, least_conn, ip_hash ( |
roundrobin, leastconn, uri u.a. (Spezialist) |
L4-/TCP-Proxy |
nein |
ja ( |
ja |
Architektur |
hybrid Multi-Process/Multi-Thread, Threads nur bei aktiver Verarbeitung (event) |
Master/Worker, ereignisgesteuert |
Multi-Thread, ereignisgesteuert |
HTTP/2 |
ja |
ja |
ja |
HTTP/3 (QUIC), RHEL-10-Build |
nein |
ja |
nein |
Aktive Health Checks |
ja ( |
nur Plus (OSS: passiv) |
ja |
Caching |
|
|
klein, eingebaut |
LDAP / Active Directory |
ja ( |
nur extern ( |
nein |
Kerberos / SPNEGO (SSO) |
ja ( |
nur Drittmodul |
nein |
OAuth / OIDC (SSO) |
ja ( |
Plus oder extern |
extern (oauth2-proxy, SPOE) |
SAML (SSO) |
ja ( |
Plus oder externer SP |
nur externer SP |
Web Application Firewall |
Add-on (ModSecurity/Coraza) |
Add-on (ModSecurity-Connector) |
SPOA-Anbindung oder Enterprise |
Ressourcenbedarf |
moderat (event MPM) |
niedrig |
sehr niedrig |
RHEL-10-Paket (Stand 10.1) |
|
|
|
Architektur¶
Apache arbeitet prozess- und threadbasiert. Das Multi-Processing Module (MPM) bestimmt das Modell; unter RHEL 10 ist event der Standard. Beim event-MPM bedienen mehrere Kindprozesse mit je einem festen Satz Worker-Threads die Requests, während ein eigener Listener-Thread die ruhenden Keep-Alive-Verbindungen ereignisgesteuert offenhält. Das senkt den Ressourcenbedarf gegenüber dem älteren worker-MPM deutlich. Pro aktivem Request belegt Apache aber weiterhin einen Thread, weshalb nginx und HAProxy unter hoher Parallelität schlanker bleiben.
Der Ruf, Apache sei generell ressourcenhungrig, stammt aus der Zeit des alten prefork-Modells (ein Prozess pro Verbindung) zusammen mit mod_php. Unter RHEL 10 wird mod_php nicht mehr ausgeliefert; PHP läuft über PHP-FPM. prefork ist nur noch für die wenigen nicht-threadsicheren Module nötig.
nginx besteht aus einem Master-Prozess und einer festen Anzahl Worker-Prozesse, als Richtwert einer pro CPU-Kern. Jeder Worker ist ereignisgesteuert und asynchron und hält tausende Verbindungen, ohne pro Verbindung einen Thread zu binden.
HAProxy läuft als ein einzelner Prozess mit mehreren Threads, per Default einer pro nutzbarem CPU-Kern. Jeder Thread arbeitet ereignisgesteuert. Von den dreien ist HAProxy am genügsamsten. Die früher verbreitete Aussage, HAProxy sei single-threaded, trifft seit Version 1.8 nicht mehr zu.
Protokolle¶
Apache spricht HTTP/1.0, HTTP/1.1 und HTTP/2 (mod_http2). Als Reverse Proxy bindet mod_proxy zusätzlich FastCGI (PHP-FPM), AJP (Tomcat), WebSocket (mod_proxy_wstunnel) und uwsgi an. HTTP/3 beherrscht Apache nicht.
nginx spricht HTTP/1.0, HTTP/1.1, HTTP/2 und HTTP/3/QUIC; der RHEL-10-Build ist mit --with-http_v3_module compiliert. Backends bindet es über FastCGI, uwsgi, SCGI und gRPC an. Das stream-Modul vermittelt zusätzlich reines TCP und UDP auf Layer 4, etwa für Datenbanken oder SMTP.
HAProxy vermittelt im TCP-Modus jedes TCP-basierte Protokoll (Layer 4) und im HTTP-Modus HTTP/1.1, HTTP/2 und gRPC (Layer 7). HTTP/3 unterstützt HAProxy im Quellcode, die RHEL-10- und Fedora-Builds sind aber ohne QUIC compiliert.
Load Balancing, Health Checks und Caching¶
Apaches mod_proxy_balancer kennt vier Verfahren: byrequests (gewichtetes Round-Robin nach Anzahl Requests), bytraffic (nach übertragenem Datenvolumen), bybusyness (an die am wenigsten ausgelastete Instanz) und heartbeat (anhand von Heartbeat-Daten). nginx bietet mit upstream round-robin, least_conn, ip_hash und hash. HAProxy hat den grössten Funktionsumfang und ist hier der Spezialist.
Bei den Health Checks prüft Apache aktiv über mod_proxy_hcheck. Open-Source-nginx kennt nur passive Checks, klinkt fehlerhafte Backends also erst nach echten Fehlern temporär aus; aktive Checks gibt es nur in nginx Plus. HAProxy prüft aktiv und passiv und lässt sich dabei fein steuern.
Beim Caching liefert Apache mod_cache und mod_cache_disk. nginx bringt mit proxy_cache einen robusten plattenbasierten Reverse-Proxy-Cache mit, der oft als schlanker Varnish-Ersatz dient. HAProxy hat nur einen kleinen eingebauten Cache für sehr kleine Objekte; echtes Caching übernimmt eine vorgelagerte Instanz.
Module und Authentifizierung¶
Apaches eigentliche Stärke ist das Modul-Ökosystem samt der per-Verzeichnis-Konfiguration über .htaccess. Für Authentifizierung und Identitäten bindet Apache direkt an LDAP und Active Directory (mod_authnz_ldap), an Kerberos/SPNEGO (mod_auth_gssapi), an OIDC-Identity-Provider (mod_auth_openidc) und an SAML (mod_auth_mellon) an. Die meisten dieser Module liegen in den RHEL-10-Basis-Repos.
Dazu kommen Funktionen, die ein reiner Proxy nicht mitbringt: komplexe Regelwerke (mod_rewrite), Response-Manipulation (mod_substitute, mod_sed, mod_headers), serverseitige Skripte (mod_lua), WebDAV (mod_dav) sowie Session-Handling (mod_session, mod_auth_form). Die vollständige Liste führt die Apache-Modulübersicht.
nginx hat einen kleineren Modulsatz und löst Authentifizierung meist über auth_request, also per Rückfrage an einen externen Dienst. HAProxy ist kein Inhaltsserver; Authentifizierung gegen OAuth oder OIDC läuft über vorgelagerte Helfer wie oauth2-proxy oder über die SPOE-Schnittstelle. Wer also AD-Anbindung, SSO oder viele Spezialmodule braucht, ist mit Apache am besten bedient.
TLS und Web Application Firewall¶
Alle drei terminieren TLS über OpenSSL 3.x aus RHEL 10, inklusive TLS 1.3, SNI und aktueller Cipher-Suites.
Eine WAF bringt keiner im Standard mit. Apache und nginx binden ModSecurity beziehungsweise dessen Nachfolger Coraza als Modul oder Connector an. HAProxy nutzt dafür eine SPOA-Anbindung (etwa ModSecurity- oder Coraza-SPOA) oder die kommerzielle HAProxy Enterprise.
Entscheidungshilfe¶
Applikationshosting, komplexe Anforderungen, tiefe Auth-Integration (AD/LDAP, Kerberos, OIDC-SSO),
mod_rewrite-Regelwerke,.htaccessund ein breites Modul-Ökosystem: Apache.Hohe Parallelität, schnelle statische Auslieferung, Reverse Proxy mit Caching und HTTP/3: nginx.
Reine Lastverteilung und Proxying für HTTP und beliebige TCP-Dienste, maximale Health-Check- und Balancing-Optionen bei minimalem Ressourcenbedarf: HAProxy.