Load balancer

At layer 7 it ends the client's connection, reads HTTP and opens its own to a backend, adding x-forwarded-for; at layer 4 it passes bytes through without reading them. Policies include round robin and source hash (sticky), and least connections. Health checks take failing backends out; draining takes one out on purpose.

How load balancing works, step by step

Clients know one address, the balancer's. Behind it sit several identical servers, its backends. Follow one HTTP request through a layer 7 balancer:

1. The client connects to the balancer. Its DNS name points at the balancer's address, and the TCP handshake (and TLS, if the balancer holds the certificate) ends there.
2. The balancer reads the request and picks a backend by its policy:
   • round robin: the next backend in turn;
   • least connections: the backend with the fewest open connections, best when requests differ in cost;
   • source hash: a hash of the client's address, so one client always reaches the same backend ("sticky");
   • or by content: /api to one pool, images to another.
3. It opens its own connection to that backend and sends the request on, adding X-Forwarded-For with the client's address, because the backend now sees the balancer as the source.
4. The response comes back the same way, and the balancer logs who asked, which backend answered, the status and the timings.

A layer 4 balancer stops at step 2's first half: it picks a backend per TCP connection and copies bytes both ways without reading them. It is faster and works for any protocol, but cannot route by URL or add headers. Some layer 4 balancers do not even proxy: they rewrite addresses (NAT) or forward frames, and the backend answers the client directly.

Meanwhile the balancer runs health checks: every second or so it asks each backend for a page such as /health. A few failures in a row take the backend out of the rotation; a few successes put it back. An operator can also drain a backend: no new requests, open ones allowed to finish, then maintenance.

What it looks like on a Linux machine

In the load balancing lab HAProxy balances three web servers. The heart of its configuration:

backend web
    balance roundrobin
    option httpchk GET /health
    option forwardfor
    server webA 10.0.2.11:80 check inter 1s fall 2 rise 2
    server webB 10.0.2.12:80 check inter 1s fall 2 rise 2
    server webC 10.0.2.13:80 check inter 1s fall 2 rise 2

Six requests from the laptop come back from A, B, C, A, B, C, and each one is a line in HAProxy's log, naming the client, the frontend and the chosen backend:

10.0.1.11:53412 [10/Oct/2026:12:00:01.123] web web/webB 0/0/0/1/1 200 162 - - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"

The five timings are milliseconds: waiting for the request, in the queue, connecting to the backend, waiting for its response, and the total. Stop webB and within two or three seconds the log says why it left:

Server web/webB is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 2 active and 0 backup servers left.

The runtime socket (show servers state, disable server web/webA) drains a server by hand.

What goes wrong, and how you see it

One slow backend, many waiting users. Round robin keeps sending it its share, and its open requests pile up. The lab slows webB by 300 ms and compares round robin with least connections: the second sends it far fewer.

A health check that tests too little. A server whose database is gone still answers /. Make the check page exercise what the application needs, and watch for Layer7 wrong status in the log.

Sessions that vanish. An application that keeps sessions in one server's memory breaks under round robin. Sticky balancing hides it until that server fails; a shared session store fixes it.

Every client looks the same. Backend logs show only the balancer's address. Read X-Forwarded-For, or the PROXY protocol for layer 4, and trust it only from the balancer.

The balancer is the single point of failure. Real deployments run two, sharing a virtual address with VRRP.

Questions people ask

What is the difference between a load balancer and a reverse proxy? A reverse proxy accepts requests for servers behind it; a load balancer is a reverse proxy, or a layer 4 device, that spreads them over several.

Layer 4 or layer 7? Layer 7 when you need HTTP features: routing by path, headers, retries on errors. Layer 4 for other protocols, or TLS the balancer should not decrypt.

Is DNS round robin load balancing? Partly. Several A records spread clients, but clients cache answers and DNS does not know when a server is down.

See it on real machines