Mastering Load Balancing: LVS, Nginx, and HAProxy Explained

Most Internet systems today rely on server clusters, where identical services are deployed on multiple machines to form a unified service. A load‑balancing server sits in front of a web‑server cluster, receives client requests, and forwards them to the most suitable backend server, making the forwarding transparent to the client.

Cloud computing and distributed architectures essentially package backend servers as compute and storage resources, presenting them as a single, seemingly limitless server to the client, while the real work is performed by the underlying cluster.

LVS, Nginx, and HAProxy are the three most widely used software load balancers.

Choosing a load balancer depends on site scale: small to medium sites (PV < 10 million) can use Nginx; larger deployments may use DNS round‑robin or LVS; very large or critical services often adopt LVS with Keepalived.

A common modern architecture is: front‑end load balancer (Nginx/HAProxy + Keepalived) → backend MySQL master‑slave with read/write separation → LVS + Keepalived for high‑availability.

LVS (Linux Virtual Server)

LVS is built into the Linux kernel (since 2.4) and provides layer‑4 (transport‑layer) load balancing for TCP/UDP traffic. Its architecture consists of three parts: the front‑end Load Balancer, the middle Server Array, and the bottom Shared Storage.

Unlike layer‑7 solutions, LVS cannot parse HTTP URLs; it forwards packets based on IP address and port. It supports two forwarding modes:

NAT mode : LVS modifies destination IP (DNAT) to the real server and source IP (SNAT) back to the virtual IP, making the client see LVS as the responder.

DR mode : LVS only changes the MAC address, leaving IPs untouched; the real server replies directly to the client, reducing bandwidth bottlenecks and improving performance.

Advantages of LVS include strong load capacity, low CPU/memory usage, stability with built‑in hot‑standby (e.g., LVS + Keepalived), and applicability to any TCP/UDP service. Drawbacks are the lack of regex support, inability to perform content‑based routing, and higher complexity compared to Nginx/HAProxy for very large sites.

Nginx

Nginx is a high‑performance web server and reverse‑proxy that uses an event‑driven, asynchronous, single‑threaded architecture with a master process and multiple worker processes. It employs epoll for massive concurrency and low memory consumption.

Its load‑balancing operates at layer 7, handling HTTP/HTTPS traffic. Nginx supports several upstream strategies:

Round‑robin (default)

Weight‑based round‑robin

ip_hash (session persistence)

fair (third‑party, based on response time)

url_hash (third‑party, directs same URL to same backend)

Key benefits are cross‑platform support, simple configuration, non‑blocking high concurrency (tens of thousands of connections), built‑in health checks, bandwidth savings via GZIP, and high stability. Limitations include support only for HTTP/HTTPS/TCP/Email protocols and lack of native session persistence beyond ip_hash.

HAProxy

HAProxy provides both TCP (layer 4) and HTTP (layer 7) proxying and supports virtual hosting. It complements Nginx by offering richer session‑persistence features, cookie‑based routing, and URL‑based health checks.

Performance-wise, HAProxy often surpasses Nginx in raw load‑balancing speed and handles high concurrency efficiently. It offers numerous algorithms such as round‑robin, weighted round‑robin, source (original address), RI (request URL), and rdp‑cookie.

Overall, selecting among LVS, Nginx, and HAProxy should consider traffic volume, required layer of inspection, configuration complexity, and specific feature needs.