Understanding LVS, Nginx, and HAProxy: Choosing the Right Load Balancer for Your Web Architecture

Overview of Load Balancing in Distributed Systems

Modern internet services are typically deployed as clusters of identical servers (web, database, cache, etc.). A load‑balancing node sits in front of the cluster, receives client requests, and forwards each request to an appropriate backend server, presenting a single logical service to the client. Layer‑4 (transport‑layer) and layer‑7 (application‑layer) balancers differ in the information they use for routing.

Linux Virtual Server (LVS)

Architecture

LVS is part of the Linux kernel since version 2.4 and provides layer‑4 load balancing. The typical deployment consists of three logical parts:

Load Balancer (front‑end) : a virtual IP (VIP) that receives client traffic.

Server Array (middle layer) : the pool of real servers (RS) that actually process requests.

Shared Storage (back‑end) : optional storage shared among the real servers.

Forwarding Mechanisms

LVS makes routing decisions based on the destination IP address and port; it does not inspect HTTP URLs. Two primary forwarding modes are used:

NAT mode (Network Address Translation) : LVS rewrites the destination IP to the RS’s IP (DNAT). The RS’s reply is sent back to LVS, which then rewrites the source IP to the VIP (SNAT) before forwarding to the client. This mode places both inbound and outbound traffic through the balancer.

DR mode (Direct Routing) : LVS only changes the Ethernet MAC address of the packet, leaving the IP addresses untouched. The RS sends the response directly to the client, bypassing the balancer on the return path. DR mode eliminates the balancer from the data path, offering higher throughput.

Advantages

Very low CPU and memory consumption because only packet headers are processed.

Simple configuration reduces operational errors.

Built‑in hot‑standby (e.g., LVS + Keepalived) provides high availability.

No traffic passes through the balancer in DR mode, preserving I/O performance.

Supports any TCP/UDP service.

Disadvantages

Cannot perform layer‑7 functions such as URL‑based routing, regex matching, or content‑based switching.

Deployment complexity grows for large web applications compared with solutions that combine layer‑7 features (e.g., Nginx + Keepalived).

Nginx

Architecture

Nginx is an event‑driven, asynchronous web server and reverse proxy. It runs one master process and multiple worker processes; each worker handles many connections via the epoll (or kqueue) mechanism, avoiding per‑connection threads or processes.

Layer‑7 Load Balancing

Using the upstream directive, Nginx distributes HTTP/HTTPS requests according to several algorithms:

Round‑robin (default)

Weighted round‑robin

IP hash (session affinity)

Fair (response‑time based, third‑party module)

URL hash (third‑party module)

Advantages

Cross‑platform (Unix‑like OSes and Windows).

Configuration syntax is concise and program‑like.

Non‑blocking design handles tens of thousands of concurrent connections with low memory (≈15 MB per worker).

Built‑in health checks and optional GZIP compression reduce bandwidth.

Limitations

Only supports HTTP/HTTPS and mail protocols; cannot balance arbitrary TCP/UDP services.

Health checks are limited to simple port probing; native session persistence requires ip_hash or external modules.

HAProxy

Supported Modes

HAProxy can operate as both a layer‑4 (TCP) and layer‑7 (HTTP) proxy, and it supports virtual hosting.

Load‑Balancing Algorithms

Round‑robin

Weighted round‑robin

Source (IP‑preserving)

Request‑URL

Cookie‑based routing

Key Features

Session persistence via cookies or source IP.

Extensive health‑checking, including HTTP URL checks.

High throughput for pure load‑balancing workloads, often exceeding Nginx in TCP mode.

Can be combined with LVS + Keepalived for MySQL read‑write splitting or other TCP services.

Advantages

Handles both TCP and HTTP traffic, covering use cases that Nginx cannot.

Rich set of health‑check options and fine‑grained control over routing decisions.

Generally higher performance for large numbers of concurrent connections.

Disadvantages

Configuration is more verbose than Nginx’s simple upstream block.

Does not provide a built‑in web server for static content (requires a separate server).

Typical Deployment Patterns

For small‑to‑medium web sites (daily PV < 10 M), Nginx alone is often sufficient. Large‑scale services with many backend nodes typically use a hybrid approach: Nginx or HAProxy + Keepalived for HTTP traffic, and LVS + Keepalived for TCP‑level load balancing (e.g., MySQL master‑slave clusters).