HAProxy oder Nginx als Reverse Proxy: Wie ich mich entscheide

Nginx und HAProxy werden ständig miteinander verglichen. Die ehrliche Antwort ist: Es gibt massive Überschneidungen. Beide können TLS terminieren, Traffic über mehrere Backends balancieren und Anfragen basierend auf Hostnames oder Pfaden routen. Für eine gewaltige Anzahl von Setups funktioniert beides absolut einwandfrei.

Aber sie wurden mit völlig unterschiedlichen Hauptaufgaben im Hinterkopf entwickelt. Und dieser Unterschied wird schmerzhaft offensichtlich, sobald das eigene Setup über "ein einzelner App-Server hinter einem Proxy" hinauswächst.

Nginx: Der Standard für einen einzelnen App-Server

Wenn Sie exakt einen einzigen Applikationsserver haben, vielleicht gepaart mit ein paar Verzeichnissen für statische Assets, und die Aufgabe des Proxys hauptsächlich in der TLS-Terminierung und dem simplen Routen von Requests besteht, ist Nginx die simplere Wahl. Es macht diesen Job extrem gut:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location /static/ {
        root /var/www/example.com;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Diese Konfiguration erledigt drei Jobs auf einmal: Sie liefert statische Dateien direkt aus, terminiert TLS und leitet alles andere als Proxy an die Applikation weiter. Für ein einzelnes Backend ist das exakt das richtige Maß an Komplexität. Außerdem hat fast jeder Entwickler schon einmal Nginx-Syntax gesehen. Das ist ein enormer Vorteil, wenn man nicht die einzige Person ist, die das System warten muss.

HAProxy: Der Standard, sobald es mehr als ein Backend gibt

In der Sekunde, in der Sie eine zweite Instanz Ihrer Applikation hochfahren, ändern sich die Fragen grundlegend. Welche Backends sind aktuell überhaupt gesund? Wie soll die Last verteilt werden? Was passiert mit einem Request, der gerade verarbeitet wird, wenn ein Backend plötzlich stirbt?

Genau das ist der Kernjob von HAProxy, und das zeigt sich sofort daran, wie direkt die Konfiguration das ausdrückt:

frontend web
    bind *:443 ssl crt /etc/haproxy/certs/example.com.pem
    default_backend app_servers

backend app_servers
    balance roundrobin
    option httpchk GET /healthz
    server app1 10.0.0.11:3000 check
    server app2 10.0.0.12:3000 check
    server app3 10.0.0.13:3000 check

option httpchk GET /healthz bedeutet, dass HAProxy aktiv den Health-Endpunkt jedes Backends abfragt. Wenn ein Backend diese Checks nicht mehr besteht, nimmt HAProxy es vollautomatisch aus der Rotation. Null manuelle Eingriffe erforderlich.

Die integrierte Statistik-Seite von HAProxy liefert eine detaillierte Live-Ansicht darüber, welche Backends online sind, wie viele Verbindungen jedes einzelne gerade verarbeitet und wie die Antwortzeiten pro Backend aussehen. Diese Observability wird absolut unverzichtbar, sobald man mehr als einen Server im Blick behalten muss.

Beide gemeinsam nutzen

Diese Tools schließen sich keineswegs gegenseitig aus. Eine sehr verbreitete Architektur zur Skalierung über einen einzelnen Server hinaus platziert HAProxy ganz nach vorne an den Edge. HAProxy übernimmt die TLS-Terminierung und das Load Balancing über mehrere App-Server hinweg. Jeder dieser App-Server betreibt dann lokal einen eigenen Nginx, um statische Dateien auszuliefern und Requests direkt an den Applikations-Prozess weiterzuleiten.

HAProxy muss nichts über statische Dateien wissen. Nginx muss nichts über den restlichen Server-Cluster wissen. Jede Komponente macht exakt den Job, den sie am besten kann.

Die eigentliche Entscheidung

Wenn Sie ein einziges Backend haben und das Hauptziel TLS-Terminierung plus grundlegendes Routing ist, ist Nginx simpler, vertrauter und völlig ausreichend. HAProxy vor ein einzelnes Backend zu setzen, fügt einen kompletten Netzwerk-Layer hinzu, ohne wirklich neue Fähigkeiten zu bringen.

Aber wenn Sie mehr als eine Backend-Instanz haben und gesundheitsbasiertes Load Balancing wirklich wichtig wird (selbst wenn es nur zwei App-Server aus Redundanzgründen sind), ist HAProxy exakt dafür gebaut. Zu versuchen, das robuste Health-Check-Modell von HAProxy in Nginx nachzubauen, bedeutet den Einsatz von Third-Party-Modulen oder das Schreiben von weit komplexeren Konfigurationen, als HAProxy für exakt dasselbe Ergebnis benötigt.

Die Frage ist nicht, welches Tool objektiv besser ist. Die Frage ist, ob "An welches Backend soll dieser Request gehen, und ist das Backend überhaupt noch gesund?" ein Problem ist, das Ihre Infrastruktur beantworten muss. Sobald das der Fall ist, hat HAProxy seinen Platz mehr als verdient.