Choosing the Right Load Balancer: LVS, Nginx, HAProxy or F5 Explained

Problem Background

In production, a single server’s processing capacity is limited. When request volume grows beyond what one machine can handle, traffic must be distributed across multiple servers. Load balancing is the core technology that solves this problem.

Four Load‑Balancing Solutions Overview

LVS – kernel‑level, four‑layer (TCP/UDP), supports millions of concurrent connections, ideal for high‑throughput entry points and DDoS protection.

Nginx – software, seven‑layer (HTTP/HTTPS), suitable for web reverse‑proxy, URL‑based routing, SSL termination, and request rewriting.

HAProxy – software, supports both four‑ and seven‑layer, strong ACL routing, rich health‑check options, and flexible session‑persistence.

F5 BIG‑IP – hardware/virtual ADC, provides both four‑ and seven‑layer load balancing with enterprise‑grade performance, reliability and support.

LVS – Linux Virtual Server

Principle

LVS uses the IPVS kernel module to forward packets in kernel space, offering extremely high performance.

Three operating modes:

NAT – Director rewrites destination IP/port, all traffic passes through the director.

DR (Direct Routing) – Director only changes MAC address; the real server replies directly to the client, reducing load on the director.

TUN (IP Tunneling) – Similar to DR but uses an IP tunnel, allowing cross‑subnet deployments.

Architecture & Deployment

Typical "Director + Real Server" architecture, often combined with Keepalived for high availability.

Client --> LVS‑Director --> RS --> LVS‑Director --> Client

Configuration Example

Install ipvsadm and keepalived, create a virtual service, define real servers, and enable health‑check scripts. Example snippets:

# CentOS/RHEL
yum install -y ipvsadm keepalived
# Ubuntu/Debian
apt-get update && apt-get install -y ipvsadm keepalived

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 0
    protocol TCP
    real_server 192.168.1.20 80 { weight 1 }
    real_server 192.168.1.21 80 { weight 1 }
}

Scheduling Algorithms

rr – round‑robin

wrr – weighted round‑robin

lc – least connections

wlc – weighted least connections

sh – source hash (session persistence)

dh – destination hash (cache scenarios)

sed – shortest expected delay

nq – never queue (high‑performance)

Pros & Cons

Advantages

Kernel‑space forwarding gives microsecond‑level latency.

Supports TCP/UDP load balancing for databases, message queues, etc.

Multiple operating modes cover many scenarios.

Works with Keepalived for HA.

Disadvantages

Configuration is complex; requires kernel and ARP knowledge.

In NAT mode the director can become a bottleneck.

No seven‑layer features such as URL rewriting.

Health‑check functionality is basic.

Nginx – Seven‑Layer Load Balancer

Principle

Nginx operates at the application layer, parses HTTP/HTTPS, and can route based on URL, headers, cookies, or perform SSL termination.

Typical Use Cases

URL‑based routing (e.g., /api/ → API service, /web/ → web service)

Header‑based routing (Host, User‑Agent)

Session persistence via cookies

SSL termination

Request modification and access control

Configuration Example

# Install Nginx
yum install -y nginx
# or
apt-get install -y nginx

worker_processes auto;
worker_rlimit_nofile 65535;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 65535;
    use epoll;
    multi_accept on;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" upstream: $upstream_addr upstream_status: $upstream_status';
    access_log /var/log/nginx/access.log main;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    # Rate limiting
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=addr:10m;

    upstream web_cluster {
        least_conn;
        server 192.168.2.20:8080 weight=5;
        server 192.168.2.21:8080 weight=5;
        server 127.0.0.1:8080 backup;
        keepalive 32;
    }

    server {
        listen 80;
        server_name example.com;
        client_max_body_size 100m;
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
        proxy_send_timeout 300s;
        location / { proxy_pass http://web_cluster; }
        location /api/ { proxy_pass http://api_backend; }
        location /static/ { proxy_pass http://static_backend; expires 7d; add_header Cache-Control "public, no-transform"; }
        location /health.html { return 200 'OK'; access_log off; }
    }

    # HTTPS termination
    server {
        listen 443 ssl http2;
        server_name example.com;
        ssl_certificate /etc/nginx/ssl/example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/example.com.key;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 10m;
        location / { proxy_pass http://web_cluster; }
    }
}

Scheduling Algorithms

roundrobin (default)

least_conn

ip_hash (session persistence)

hash $request_uri (URL hash)

Pros & Cons

Advantages

Simple configuration, gentle learning curve.

Rich seven‑layer features (URL rewrite, request modification, rate limiting).

Native SSL termination.

High performance, event‑driven architecture.

Active community and ecosystem.

Disadvantages

Four‑layer performance is lower than LVS.

Health‑check capabilities are basic (open‑source version).

Does not support UDP load balancing.

HAProxy – Hybrid Load Balancer

Principle

HAProxy supports both TCP (four‑layer) and HTTP/HTTPS (seven‑layer) load balancing. It offers flexible ACL routing, rich health‑check options, and strong session‑persistence mechanisms.

Configuration Example

# Install HAProxy
yum install -y haproxy
# or
apt-get install -y haproxy

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /var/run/haproxy-admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 40960
    nbthread 4
    tune.bufsize 16384
    tune.ssl.default-dh-param 2048

defaults
    log global
    mode http
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor except 127.0.0.0/8
    option redispatch
    retries 3
    timeout connect 10s
    timeout client 30s
    timeout server 30s
    timeout http-request 10s
    timeout http-keep-alive 10s

listen stats
    bind :8404
    stats enable
    stats uri /stats
    stats refresh 30s
    stats realm HAProxy\ Statistics
    stats auth admin:password123

frontend http_front
    bind :80
    mode http
    default_backend web_backend
    acl url_api path_beg /api/
    acl url_admin path_beg /admin/
    use_backend api_backend if url_api
    use_backend admin_backend if url_admin

backend web_backend
    mode http
    balance roundrobin
    option httpchk GET /health HTTP/1.0
    http-check expect status 200
    server web1 192.168.3.20:8080 check inter 2000 rise 2 fall 3 weight 100
    server web2 192.168.3.21:8080 check inter 2000 rise 2 fall 3 weight 100

backend api_backend
    mode http
    balance leastconn
    option httpchk GET /api/health
    cookie SERVERID insert indirect nocache
    server api1 192.168.3.30:8080 check inter 2000 rise 2 fall 3 weight 100 cookie api1
    server api2 192.168.3.31:8080 check inter 2000 rise 2 fall 3 weight 100 cookie api2

backend admin_backend
    mode http
    balance source
    option httpchk GET /admin/health
    server admin1 192.168.3.40:8080 check inter 2000 rise 2 fall 3

frontend mysql_front
    bind :3306
    mode tcp
    default_backend mysql_backend

backend mysql_backend
    mode tcp
    balance roundrobin
    option mysql-check user haproxy_check
    server mysql1 192.168.3.30:3306 check port 3306 inter 2000 rise 2 fall 3 weight 100
    server mysql2 192.168.3.31:3306 check port 3306 inter 2000 rise 2 fall 3 weight 100 backup

frontend redis_front
    bind :6379
    mode tcp
    default_backend redis_backend

backend redis_backend
    mode tcp
    balance leastconn
    option redis-check
    server redis1 192.168.3.50:6379 check inter 2000 rise 2 fall 3
    server redis2 192.168.3.51:6379 check inter 2000 rise 2 fall 3

frontend https_front
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    mode http
    default_backend web_backend
    acl host_api hdr(host) -i api.example.com
    acl host_static hdr(host) -i static.example.com
    use_backend api_backend if host_api
    use_backend static_backend if host_static

ACL Routing Example

# URL based
acl url_static path_beg /static /images /css /js
acl url_api path_beg /api/v1 /api/v2
# Header based
acl is_mobile req.hdr(User-Agent) -i mobile android iphone
acl is_internal src 192.168.0.0/16 10.0.0.0/8
# Cookie based
acl has_session cookie(SESSIONID) -m found
# Combine conditions
acl needs_cache url_static -i || url_api -i
# Method based
acl is_upload method POST
acl is_delete method DELETE
# Use backends
use_backend cache_backend if needs_cache
use_backend api_backend if url_api

Scheduling Algorithms

roundrobin (default)

leastconn

source (IP hash)

uri (URL hash)

url_param (URL parameter hash)

random

consistent hash

Pros & Cons

Advantages

Supports both four‑ and seven‑layer load balancing.

Highly flexible ACL routing.

Rich health‑check types (TCP, HTTP, MySQL, Redis).

Multiple session‑persistence methods (cookie, source IP).

Comprehensive statistics page.

Excellent performance with low latency.

Disadvantages

Configuration complexity and steep learning curve.

Hot reload causes brief connection interruption.

Documentation can be terse.

F5 – Hardware Load Balancer

Overview

F5 BIG‑IP is an enterprise‑grade appliance offering four‑ and seven‑layer load balancing with hardware acceleration, high reliability, and vendor support.

Key Concepts

Virtual Server – public IP + port presented to clients.

Pool – logical group of backend members.

Pool Member – individual backend IP + port.

Node – backend server IP.

Health Monitor – checks backend availability.

iRule – TCL‑based traffic scripting for custom logic.

Profile – protocol‑specific settings (HTTP, SSL, etc.).

Basic Configuration Workflow (Big‑IP LTM)

Create nodes:

# TMSH
create ltm node 192.168.10.20 { address 192.168.10.20 }
create ltm node 192.168.10.21 { address 192.168.10.21 }

Create health monitors (HTTP, TCP, HTTPS) using create ltm monitor ….

Create a pool and attach nodes with the chosen monitor.

Create a virtual server that binds a VIP to the pool and selects appropriate profiles.

Optionally add an SSL client profile and attach it to the virtual server.

Common TMSH commands for status and troubleshooting (e.g., show ltm virtual, show ltm pool, show ltm node).

Pros & Cons

Advantages

Hardware‑level performance (tens of Gbps).

99.999% carrier‑grade reliability.

Full ADC feature set (SSL offload, compression, iRules, etc.).

Vendor support and SLA.

Disadvantages

High cost (hundreds of thousands of dollars).

Limited flexibility compared with software solutions.

Configuration changes require careful planning; upgrades carry risk.

Horizontal Comparison

Performance

LVS – microsecond‑level four‑layer throughput, millions of connections.

Nginx – high seven‑layer performance, tens of thousands of connections.

HAProxy – high four‑layer and seven‑layer performance, up to hundreds of thousands of connections.

F5 – hardware‑accelerated, millions of connections.

Feature Matrix (selected items)

Four‑layer support: LVS, HAProxy, F5 (Nginx no).

Seven‑layer support: Nginx, HAProxy, F5 (LVS no).

Health checks: Basic (LVS, Nginx) vs Rich (HAProxy, F5).

Session persistence: All support.

URL routing: Nginx, HAProxy, F5 (LVS no).

SSL termination: Nginx, HAProxy, F5 (LVS no).

ACL rules: Nginx, HAProxy, F5 (LVS no).

High‑availability: Keepalived (LVS, Nginx) vs built‑in (HAProxy, F5).

Cost Comparison

LVS – free, low hardware cost, medium maintenance.

Nginx – free (open‑source) or commercial, low hardware, medium maintenance.

HAProxy – free, low hardware, medium maintenance.

F5 – license and hardware start at several hundred thousand, low maintenance due to vendor support.

Decision Tree (text version)

Business Scenario
│
├── Large‑traffic entry (CDN source, DNS) → LVS + Keepalived
│
├── Web reverse‑proxy / seven‑layer routing
│   ├── Simple, low‑feature needs → Nginx
│   └── Complex ACL routing → HAProxy
│
├── Database, cache (four‑layer) → HAProxy
│
├── High‑end (finance, telecom) → F5
│
└── Mixed four‑/seven‑layer → HAProxy

Practical Troubleshooting Cases

Case 1 – LVS All Real Servers Down

Symptoms : ipvsadm -Ln shows zero active connections; VIP unreachable.

Investigation Steps

Verify LVS process and Keepalived status.

Check VRRP communication (logs, tcpdump -i eth0 vrrp).

Confirm VIP is bound to the interface.

Test connectivity to each real server.

Inspect ARP settings on RS for DR mode ( /proc/sys/net/ipv4/conf/lo/arp_ignore and arp_announce).

Fixes

Restart failed backend services.

Correct ARP parameters on RS (set arp_ignore=1, arp_announce=2).

Reload Keepalived after configuration changes.

Case 2 – Nginx 502 Bad Gateway

Symptoms : curl -v http://example.com returns HTTP 502.

Investigation Steps

Check Nginx error log.

Validate upstream configuration ( nginx -t).

Confirm backend services are up and responding.

Verify backend processes and listening ports.

Inspect backend resource usage (CPU, memory, disk).

Check connection counts via stub_status and system tools.

Fixes

Restart failed backend services.

Increase worker_connections and worker_rlimit_nofile if connections are exhausted.

Adjust proxy timeouts ( proxy_connect_timeout, proxy_read_timeout).

Case 3 – HAProxy Backend Session Imbalance

Symptoms : Statistics show one server handling far more sessions than the other.

Investigation Steps

Check the configured load‑balancing algorithm.

Review server weight settings.

Look for frequent failures of a particular server.

Verify which servers are UP vs BACKUP.

Fixes

Adjust weights to balance traffic.

Switch algorithm (e.g., from leastconn to roundrobin) if server capacities differ.

Enable appropriate session‑persistence (source IP or cookie).

Case 4 – F5 Virtual Server Inaccessible

Investigation Steps

Show virtual server status.

Check pool member health.

Inspect node status.

Verify VLAN and self‑IP configuration.

Review routing tables.

Confirm SSL certificates if using HTTPS.

Fixes

Restart or fix any down pool members.

Re‑upload or recreate SSL certificates and profiles.

Production‑Level Risk Reminders

LVS Risks

DR mode ARP misconfiguration can break traffic flow.

NAT mode may become a bottleneck under heavy load.

Keepalived split‑brain scenarios can cause VIP conflict.

Conflicting iptables rules may interfere with LVS.

Nginx Risks

Insufficient worker_connections limits concurrency.

Improper upstream keepalive settings can waste memory.

Missing X‑Forwarded‑For header loses client IP.

All upstreams down returns 502; configure backup servers.

HAProxy Risks

Reloading may drop existing connections.

Mis‑configured maxconn can cause queuing or rejection.

Overly aggressive health checks may overload backends.

Port conflicts when backend services listen on the same port.

F5 Risks

Unsaved configuration changes are lost on reboot.

Expired license throttles throughput to 10 Mbps.

Complex iRules can degrade performance under high traffic.

Firmware upgrades carry risk; always backup configuration first.

Conclusion

Each load‑balancing solution fits distinct scenarios:

LVS – best for ultra‑high‑throughput four‑layer entry points; simple but limited feature set.

Nginx – ideal for web reverse‑proxy and seven‑layer routing with easy configuration.

HAProxy – most versatile software option, handling both four‑ and seven‑layer traffic with rich ACLs and health checks.

F5 – suited for finance, telecom, or other high‑availability, high‑performance environments where cost is less of a concern.

Common production patterns include combining LVS as a front‑door four‑layer load balancer with Nginx or HAProxy for application‑level routing, or using HAProxy alone as a unified entry point. Selecting the right solution requires weighing traffic volume, feature requirements, operational expertise and budget.