NGINX als Load Balancer – Lastverteilung mit Round Robin, Least Connections & IP Hash

Moderne Webanwendungen müssen oft Millionen von Anfragen gleichzeitig verarbeiten. Damit kein einzelner Server überlastet wird, kommt Load Balancing ins Spiel – also die intelligente Verteilung von Anfragen auf mehrere Server.

Einer der beliebtesten und effizientesten Load Balancer ist: NGINX. In diesem Artikel erfährst du, wie NGINX als Load Balancer funktioniert, welche Strategien es gibt und wie du Round Robin, Least Connections und IP Hash in wenigen Schritten konfigurierst.

1. Was ist Load Balancing?

Load Balancing bedeutet: eingehende Anfragen werden gleichmäßig oder gezielt auf mehrere Server verteilt. Das sorgt für:

• Höhere Performance (mehr gleichzeitige Nutzer)
• Bessere Ausfallsicherheit (wenn ein Server ausfällt, übernehmen andere)
• Gleichmäßige Lastverteilung
• Skalierbarkeit bei Wachstum

NGINX fungiert dabei als sogenannter Reverse Proxy Load Balancer: Er empfängt alle Anfragen, prüft die Auslastung und verteilt sie intelligent auf mehrere Backend-Server.

2. Wie funktioniert NGINX als Load Balancer?

NGINX arbeitet mit einem Upstream-Block, in dem du alle Backend-Server definierst, und einem Server-Block, der die Anfragen entgegennimmt.

Beispielgrundlage:

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
}

server {
    listen 80;
    server_name meine-seite.de;

    location / {
        proxy_pass http://backend;
    }
}

In diesem Beispiel leitet NGINX Anfragen an zwei Server weiter. Standardmäßig verwendet NGINX dafür das Round Robin-Verfahren.

3. Load-Balancing-Methoden im Überblick

NGINX bietet mehrere Strategien zur Lastverteilung – je nach Bedarf und Serverstruktur.

1. Round Robin (Standardverfahren)

Das einfachste und meistgenutzte Verfahren. NGINX verteilt die Anfragen gleichmäßig in Reihenfolge an alle verfügbaren Server.

Beispiel:

upstream backend {
    server 192.168.0.101;
    server 192.168.0.102;
    server 192.168.0.103;
}

💡 Vorteil: Einfach, effektiv und perfekt für gleich starke Server. ❌ Nachteil: Berücksichtigt keine aktuelle Serverauslastung.

2. Least Connections

Hier sendet NGINX neue Anfragen an den Server mit den wenigsten aktiven Verbindungen. Ideal für Umgebungen mit unterschiedlich starker Server-Hardware oder ungleichmäßigen Requests.

Beispiel:

upstream backend {
    least_conn;
    server 192.168.0.101;
    server 192.168.0.102;
    server 192.168.0.103;
}

💡 Vorteil: Dynamisch und ressourcenschonend. ❌ Nachteil: Etwas mehr Overhead durch laufende Verbindungsüberwachung.

3. IP Hash

Mit dieser Methode sorgt NGINX dafür, dass derselbe Client (gleiche IP-Adresse) immer beim gleichen Backend-Server landet. Ideal für Session-basierte Anwendungen (z. B. Logins oder Warenkörbe).

Beispiel:

upstream backend {
    ip_hash;
    server 192.168.0.101;
    server 192.168.0.102;
    server 192.168.0.103;
}

💡 Vorteil: Session-Stickiness ohne externe Tools. ❌ Nachteil: Ungleichmäßige Verteilung bei vielen Clients mit derselben IP (z. B. Firmennetzwerke).

4. Erweiterte Optionen

Gewichtete Server (Weighted Load Balancing)

Du kannst Servern unterschiedliche Gewichtungen zuweisen – z. B. wenn ein Server leistungsstärker ist.

upstream backend {
    server 192.168.0.101 weight=3;
    server 192.168.0.102 weight=1;
}

Der erste Server erhält dreimal so viele Anfragen wie der zweite.

Health Checks (Server-Verfügbarkeit prüfen)

Wenn ein Backend-Server ausfällt, kann NGINX ihn automatisch überspringen, bis er wieder erreichbar ist. Das passiert standardmäßig über einfache Fehlererkennung – z. B. bei Timeout oder TCP-Fehlern.

Du kannst auch explizite Optionen setzen:

server 192.168.0.103 max_fails=3 fail_timeout=30s;

Nach 3 Fehlern in 30 Sekunden wird der Server vorübergehend deaktiviert.

5. Logging und Monitoring

Zur Analyse, ob das Load Balancing funktioniert, helfen die Standard-Logs:

tail -f /var/log/nginx/access.log

Du kannst sehen, welcher Server welche Anfrage verarbeitet hat, wenn du im Log-Format Variablen ergänzt:

log_format backend '$remote_addr → $upstream_addr - $status';
access_log /var/log/nginx/loadbalancer.log backend;

So erkennst du direkt, wie die Anfragen verteilt werden.

6. Load Balancing + HTTPS

Wenn du HTTPS nutzt, kombiniere den Load Balancer mit TLS-Zertifikaten (z. B. von Let’s Encrypt):

server {
    listen 443 ssl;
    server_name meine-seite.de;

    ssl_certificate /etc/letsencrypt/live/meine-seite.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meine-seite.de/privkey.pem;

    location / {
        proxy_pass http://backend;
    }
}

Damit kannst du auch verschlüsselten Traffic sicher auf mehrere Backends verteilen.

7. Wann welche Methode?

Methode	Ideal für	Beispiel
Round Robin	Gleich starke Server	Statische Websites, APIs
Least Connections	Unterschiedlich belastete Systeme	PHP-Apps, große APIs
IP Hash	Sessionbasierte Anwendungen	Login-Systeme, Shops
Weighted	Leistungsunterschiede	Hybrid-Cluster

Mit NGINX als Load Balancer steuerst du den Datenverkehr effizient, sicher und flexibel. Egal ob du eine kleine Web-App oder ein globales Cluster betreibst – NGINX bietet mit Round Robin, Least Connections und IP Hash alles, was du für performante Lastverteilung brauchst.

Kombiniert mit SSL und Health Checks entsteht ein leistungsstarkes, hochverfügbares Setup, das jede Last souverän meistert.