HAProxy oder Nginx als Reverse Proxy: Wie ich mich entscheide

Nginx und HAProxy werden ständig verglichen, und ehrlich gesagt gibt es viel Überlappung, beide können TLS terminieren, beide können Last über mehrere Backends verteilen, beide können nach Hostname oder Pfad routen. Für sehr viele Setups würde beides funktionieren. Aber sie wurden mit unterschiedlichen Hauptaufgaben im Kopf gebaut, und das zeigt sich in den Details, sobald ein Setup über "eine Anwendung hinter einem Proxy" hinausgeht.

Nginx: der Standard für einen einzelnen Anwendungsserver

Gibt es einen Anwendungsserver, vielleicht mit ein paar Verzeichnissen für statische Assets, und die Aufgabe des Proxys ist vor allem TLS-Terminierung plus Routing an die richtige Stelle, ist Nginx die einfachere Wahl und macht das 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 Config übernimmt drei Aufgaben gleichzeitig, statische Dateien direkt ausliefern, TLS terminieren und alles andere an die Anwendung weiterleiten, und für ein einzelnes Backend ist das genau die richtige Menge Komplexität. Nginx' Konfigurationssyntax ist außerdem etwas, das die meisten Entwickler schon mal gesehen haben, was zählt, wenn auch andere diese Config anfassen müssen.

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

In dem Moment, in dem mehr als eine Instanz der Anwendung hinter dem Proxy steht, ändern sich die Fragen: Welche Backends sind gerade gesund, wie sollte die Last zwischen ihnen verteilt werden, und was passiert mit einer Anfrage mitten im Flug, wenn ein Backend stirbt. Das ist die Kernaufgabe von HAProxy, und das zeigt sich daran, wie direkt sie ausgedrückt wird:

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-Endpoint jedes Backends abfragt, und ein Backend, das anfängt, Health-Checks nicht mehr zu bestehen, fliegt automatisch aus der Rotation, kein manuelles Eingreifen nötig. Die Statistikseite von HAProxy (die stats-Direktive, meist auf einem eigenen Port) gibt einen Live-Überblick darüber, welche Backends oben sind, wie viele Verbindungen jedes davon bedient und wie die Antwortzeiten pro Backend aussehen, was wirklich nützlich wird, sobald es mehr als einen Server gibt, im Blick zu halten.

Beide zusammen nutzen

Das schließt sich nicht gegenseitig aus, und ein übliches Setup für alles, was über einen einzelnen Server hinausgeht, ist HAProxy am Rand für TLS-Terminierung und Lastverteilung über mehrere Anwendungsserver, von denen jeder Nginx laufen lässt, um statische Dateien auszuliefern und an den Anwendungsprozess weiterzuleiten. HAProxy muss nichts über statische Dateien wissen, und Nginx muss nichts über die anderen Server wissen, jeder Teil macht das, was er am besten kann.

Die eigentliche Entscheidung

Gibt es ein Backend und die Hauptaufgabe ist TLS-Terminierung plus einfaches Routing, ist Nginx einfacher, vertrauter für die meisten, die es betreuen werden, und völlig ausreichend, HAProxy vor ein einzelnes Backend zu setzen fügt eine Schicht hinzu, ohne viel Funktionalität zu gewinnen. Gibt es mehr als eine Backend-Instanz und Health-Aware-Load-Balancing ist relevant, schon bei nur zwei Anwendungsservern für Redundanz, ist HAProxys Modell für Lastverteilung und Health-Checks genau dafür gebaut, und das in Nginx nachzubauen bedeutet, zu Third-Party-Modulen oder deutlich komplexerer Konfiguration zu greifen, als HAProxy für dasselbe Ergebnis braucht.

Die Frage ist nicht, welches Tool besser ist. Es ist, ob "an welches Backend sollte diese Anfrage gehen, und ist dieses Backend überhaupt gesund" eine Frage ist, die das eigene Setup beantwortet haben muss, sobald das der Fall ist, hat sich HAProxy seinen Platz verdient.