Load Balancing heißt: Vor zwei oder mehr Server mit derselben Website kommt ein Load Balancer (nginx, HAProxy oder ein Cloud-Dienst), der eingehende Anfragen auf sie verteilt und einen ausgefallenen Server aus der Rotation nimmt. Das lohnt sich, wenn ein Server die Spitzenlast nicht mehr schafft oder die Website auch bei Neustarts und Updates erreichbar bleiben muss. Für eine kleine Website, die problemlos auf einem Hosting-Tarif läuft, ist es meist unnötig.
Unten finden Sie die vier gängigen Verteilungsverfahren mit ihren Namen in nginx und HAProxy, das Session-Problem, eine Entscheidungshilfe und die Preise verwalteter Load Balancer, die wir am 30.10.2026 auf den Seiten der Anbieter geprüft haben.
Was Load Balancing ist und wann Sie es brauchen
Load Balancing ist die Verteilung eingehender Anfragen auf mehrere Server. Läuft alles über einen einzigen Server, ist er ein Single Point of Failure: Bei Spitzenlast stauen sich die Anfragen, laufen in Timeouts, und Besucher sehen den Fehler 503 Service Unavailable oder einen 504 Gateway Timeout. Fällt der Server aus oder muss er neu starten, ist die Website weg.
Einen Load Balancer richten Sie dort ein, wo Sie eigene Server betreiben: VPS, dedizierte Server oder Cloud-Instanzen. Bei Shared Hosting konfigurieren Sie keinen Balancer selbst, um die Server kümmert sich der Anbieter. Reicht ein Tarif nicht mehr aus, ist der übliche nächste Schritt ein VPS oder ein dedizierter Server, und erst danach mehrere Server hinter einem Balancer.
Vier Verteilungsverfahren, die man kennen sollte
- Round Robin: Der Balancer verteilt die Anfragen reihum: die erste an Server A, die zweite an B, die dritte an C. Das passt, wenn die Server etwa gleich stark sind. In nginx ist es der Standard, wenn kein Verfahren angegeben ist. In HAProxy war
roundrobinbis Version 3.2 der Standard, ab Version 3.3 ist esrandom. - Least Connections: Die Anfrage geht an den Server mit den wenigsten aktiven Verbindungen. Bedient A gerade 10 Nutzer und B nur 5, landet die neue Anfrage bei B. In nginx heißt das
least_conn, in HAProxybalance leastconn. - IP Hash: Ein Nutzer landet anhand seiner IP-Adresse immer auf demselben Server. Nützlich für serverseitigen Cache und Sessions. In nginx heißt das
ip_hash(der Schlüssel sind die ersten drei Oktette einer IPv4-Adresse oder die ganze IPv6-Adresse), in HAProxybalance source. - Gewichtete Verteilung: Ein stärkerer Server bekommt mehr Anfragen. Rechenbeispiel: Mit
weight=3für A undweight=2für B gehen rund 60 % der Anfragen an A und 40 % an B. In nginx ist das Gewicht standardmäßig 1 und lässt sich auch mitleast_connundip_hashkombinieren.
Jedes Verfahren hat seinen Platz. Round Robin passt zu einfachen statischen Websites, Least Connections zu Anwendungen mit unterschiedlich langen Sitzungen, IP Hash zu Cache und Sessions und die gewichtete Verteilung zu Servern mit unterschiedlicher Ausstattung.
So funktioniert es in der Praxis
Vor den Servern steht der Load Balancer: nginx, HAProxy, ein spezialisiertes Gerät oder ein Cloud-Dienst. Er nimmt jede eingehende Anfrage an und entscheidet, an welchen Backend-Server sie weitergeht.
Entscheidend ist, was bei einem Ausfall passiert. Das Open-Source-nginx prüft passiv: Schlägt eine Anfrage an einen Server fehl, markiert nginx ihn als ausgefallen und meidet ihn eine Zeit lang. Die Standardwerte sind max_fails=1 und fail_timeout=10s, danach testet nginx den Server vorsichtig mit echten Anfragen. Aktive, regelmäßige Health Checks gehören bei nginx zum kommerziellen Abonnement. In HAProxy aktivieren Sie Prüfungen mit dem Parameter check an jeder server-Zeile: Ein Server, der keine TCP-Verbindung annimmt, fliegt aus der Rotation.
Was sich mit mehreren Servern ändert, ohne erfundene Messwerte:
| Aspekt | Ein Server | Mehrere Server hinter einem Balancer |
|---|---|---|
| Ein Server fällt aus | Website nicht erreichbar | Die übrigen Server bedienen weiter, sofern ihre Kapazität reicht |
| Neustart oder Update | Ausfallzeit | Server nacheinander aus der Rotation nehmen |
| Spitzenlast | Begrenzt durch eine Maschine | Weitere Server zum Pool hinzufügen |
| Aufwand | Eine Konfiguration | Sessions, hochgeladene Dateien, Datenbank und der Balancer selbst brauchen Planung |
| Single Point of Failure | Der Server | Der Balancer, wenn er nicht redundant oder verwaltet ist |
Ob drei kleine Server schneller sind als ein großer, hängt von Ihrer Anwendung ab, und wir haben es für diesen Artikel nicht gemessen. Prüfen Sie es selbst: Starten Sie einen Lasttest (zum Beispiel mit k6, wrk oder ab) gegen eine Testkopie, erhöhen Sie die Zahl gleichzeitiger Verbindungen, bis das 95. Perzentil der Antwortzeit oder die Fehlerquote steigt, und vergleichen Sie beide Aufbauten bei gleicher Last. Behalten Sie dabei die Datenbank im Blick: Teilen sich alle Webserver eine Datenbank, wird oft sie zum Engpass.
Sessions: wenn Load Balancing das Leben schwer macht
Hier liegt eine Falle. Ein Nutzer meldet sich auf Server A an, seine Session-Daten liegen dort. Bei der nächsten Anfrage schickt ihn der Balancer zu Server B. Dort gibt es keine Session, und der Nutzer sieht wieder die Anmeldeseite.
Das ist das Problem der Sticky Sessions. Es gibt mehrere Lösungen:
- Gemeinsamer Session-Speicher (Redis, Memcached): Die Session liegt nicht auf dem Anwendungsserver, sondern auf einem separaten Cache-Server, den alle Backends sehen.
- IP Hash im Balancer: Der Nutzer geht immer zum selben Server. Laut nginx-Dokumentation gilt das nur, solange dieser Server verfügbar ist. Fällt er aus, geht die Anfrage an einen anderen Server, und die Session ist weg.
- Daten im Cookie oder JWT-Token: Die Session reist mit dem Nutzer mit, egal zu welchem Server er geschickt wird.
Die erste Variante ist die zuverlässigste, weil kein einzelner Server eine Session exklusiv hält. Redis hält die Daten im Arbeitsspeicher und wird für diese Aufgabe häufig eingesetzt. Messen Sie seine Antwortzeit beim Lasttest trotzdem mit.
Was ein verwalteter Load Balancer kostet
Cloud-Plattformen bieten Load Balancer als Dienst an. Listenpreise ohne Steuern und ohne Backend-Server, geprüft am 30.10.2026:
| Anbieter | Produkt | Listenpreis | Hinweis |
|---|---|---|---|
| DigitalOcean | Regional Load Balancer | ab 12 USD pro Monat | Jeder Knoten bringt laut Anbieter 10.000 Anfragen pro Sekunde, 10.000 gleichzeitige Verbindungen und 250 SSL-Verbindungen pro Sekunde |
| Hetzner Cloud | LB11 | 7,49 EUR pro Monat (0,0120 EUR pro Stunde) | Bis zu 5 Services und 25 Ziele |
| AWS | Application Load Balancer, US East (N. Virginia) | 0,0225 USD pro Stunde, rund 16,43 USD für 730 Stunden, plus 0,008 USD pro LCU-Stunde | Angefangene Stunden werden voll berechnet |
Dazu kommen mindestens zwei Backend-Server und die Arbeit, sie synchron zu halten. Ein selbst betriebenes nginx oder HAProxy auf einer kleinen VM kostet nur die VM, ist dann aber selbst ein Single Point of Failure, solange kein zweiter Balancer bereitsteht. Wächst die Last, fügen Sie dem Pool einen Server hinzu: in nginx eine weitere server-Zeile im upstream-Block, in der Cloud ein weiteres Ziel.
Wer statt einzelner Server Container betreibt, zahlt bei Managed Kubernetes zusätzlich eine Gebühr für den Cluster: bei Amazon EKS rund 73 USD im Monat, noch ohne Worker-Node, wie unser Artikel über Docker, Kubernetes und echte Kosten zeigt.
Entscheidungshilfe
| Situation | Was zu tun ist |
|---|---|
| Die Website läuft auf einem Hosting-Tarif, die Antwortzeiten bleiben auch zu Spitzenzeiten gut | Kein Balancer nötig. Messen Sie regelmäßig weiter |
| Ein Server ist zu Spitzenzeiten überlastet | Zuerst Caching und Optimierung, dann ein stärkerer Server, dann mehrere Server |
| Updates ohne Ausfallzeit sind Pflicht | Zwei Server hinter einem Balancer mit Health Checks |
| Angemeldete Nutzer, Warenkörbe, Uploads | Erst gemeinsamen Session- und Dateispeicher einrichten, dann Server hinzufügen |
| Knappes Budget, eigene VMs | Verwalteter Balancer aus der Preistabelle oder nginx/HAProxy auf einer VM, Ausfallrisiko des Balancers einplanen |
Für die meisten kleinen und mittleren Websites ist der erste Schritt nicht Load Balancing, sondern Caching: Unsere Anleitung, wie Sie WordPress beschleunigen, zeigt, wo Sie anfangen. Auf Shared Hosting kümmert sich der Anbieter um die Server. Die Hosting-Tarife von RichHost beginnen bei 8 USD pro Monat, mit NVMe-Speicher und Servern in Europa und den USA.
So haben wir geprüft: Für diesen Artikel haben wir keinen eigenen Lasttest durchgeführt. Verteilungsverfahren und Standardwerte stammen aus der nginx-Dokumentation (Load Balancing, ngx_http_upstream_module) und der HAProxy-Dokumentation zu Backends, die Preise von den Seiten von DigitalOcean, Hetzner und AWS. Stand: 30.10.2026. Preise ändern sich, prüfen Sie vor dem Kauf die Seite des Anbieters. Die Gewichte 3:2 sind ein Rechenbeispiel, keine Messung.
FAQ
Brauche ich Load Balancing auf Shared Hosting?
Nein. Auf Shared Hosting konfigurieren Sie keinen Balancer, um die Server kümmert sich der Anbieter. Load Balancing richten Sie ein, wenn Sie eigene Server betreiben.
Mit welchem Verfahren sollte ich anfangen?
Mit Round Robin, wenn die Server gleich stark sind, oder mit Least Connections, wenn Anfragen sehr unterschiedlich lange dauern. Wichtiger als das Verfahren ist, Sessions und hochgeladene Dateien vorher zentral abzulegen.
Reicht IP Hash für Sessions?
Nur bedingt. Der Nutzer bleibt auf seinem Server, solange dieser läuft. Fällt er aus, landet die Anfrage woanders, und die Session ist verloren. Außerdem landen in nginx alle Nutzer mit denselben ersten drei Oktetten der IPv4-Adresse auf demselben Server.
Was kostet ein Load Balancer?
Laut Listenpreisen vom 30.10.2026 ab 7,49 EUR pro Monat (Hetzner LB11) oder ab 12 USD pro Monat (DigitalOcean), bei AWS nach Stunden und LCU. Dazu kommen die Backend-Server.
