Load Balancer

A load balancer is software that distributes incoming network traffic across multiple backend servers to improve performance, availability, and fault tolerance. Without a load balancer, a website relies on a single server, which can quickly become a bottleneck for CPU, memory, disk, or network I/O as traffic grows. More importantly, a single server creates a single point of failure. One key advantage of a load balancer is avoiding requests being forwarded to unhealthy backends. NGINX Open Source uses passive health checks by default: when a backend repeatedly fails to respond or returns errors, NGINX marks it unavailable and stops sending it new requests. Active health checks — where the load balancer proactively probes backends — are provided by NGINX Plus.

NGINX Open Source performs passive health checks by default (it detects failures from error responses/timeouts). Active health checks that periodically probe backends are available in NGINX Plus.

A diagram titled "Load Balancing With Nginx" showing clients connecting through a network cloud to an NGINX load balancer that distributes traffic to multiple web servers. Health checks are illustrated, with one server marked as unhealthy.

You can tune timeouts and failure-handling options in NGINX, but the default passive behavior ensures that unhealthy servers stop receiving traffic. If one or more web servers go down, the site remains available while you repair or replace the affected nodes.

Load-balancing algorithms supported by NGINX

NGINX supports several algorithms. Choosing the right one depends on your application workload, server capacity, and session state requirements.

Round Robin (default)
Weighted Round Robin
IP hash (sticky sessions)
Least connections (least_conn)
Least time (least_time, available in NGINX Plus)

Round Robin

Round Robin distributes requests in a circular fashion: request 1 → server A, request 2 → server B, request 3 → server C, then back to A. It is the default algorithm and works well when backend servers have similar capacity and identical content.

Define a pool of backend servers in an upstream block (typically inside http { ... } or an included file) and reference that name with proxy_pass to forward requests:

upstream backend {
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

The backend name is arbitrary — it is only a handle for the pool. An upstream can include many servers, but 3–10 servers is often more maintainable.

Weighted Round Robin

Weighted Round Robin allows assigning a weight to each server to control the relative share of requests. If server A has weight=4, B weight=2, and C weight=1, A receives four times as many requests as C.

Use weights when backends have different hardware capacity or when some servers handle more load:

upstream backend {
    server 10.10.0.101:80 weight=4;
    server 10.10.0.102:80 weight=2;
    server 10.10.0.103:80 weight=1;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Sticky sessions (`ip_hash`)

Some apps store session state locally (for example, shopping carts). To ensure a client is routed to the same backend across requests, enable ip_hash, which hashes the client IP to select a backend and provides sticky sessions.

Diagram titled "Algorithms: IP Hash" showing an NGINX load balancer using an IP-hash algorithm to route incoming requests to one of three web servers.

upstream backend {
    ip_hash;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Note: ip_hash ties clients to backends by IP, which may be problematic behind NATs or shared proxies. For more flexible session affinity, consider application-level session stores (Redis, database) or cookies.

Least connections

The least_conn algorithm sends a new request to the backend with the fewest active connections. It’s effective when request durations vary, because it avoids overloading servers currently handling long-running connections.

A diagram showing the "Least Connection" load-balancing algorithm: an NGINX load balancer directs traffic to the web server with the fewest active connections (servers shown with counts 2, 5, and 4).

upstream backend {
    least_conn;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Least time (NGINX Plus)

The least_time algorithm selects the backend with the lowest recent response time. Options like last_byte or header control whether NGINX measures time until the last response byte or until the first byte, respectively. This method is available in NGINX Plus.

The least_time balancing method (and active health checks) are available in NGINX Plus — the commercial edition.

upstream backend {
    least_time last_byte;
    server 10.10.0.101:80;
    server 10.10.0.102:80;
    server 10.10.0.103:80;
}

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://backend/;
    }
}

Quick comparison: which algorithm to choose

Algorithm	Best for	NGINX Edition
`round_robin`	Default; similar servers and identical content	Open Source
`weight` (weighted round robin)	Mixed-capacity servers	Open Source
`ip_hash`	Session affinity based on client IP	Open Source
`least_conn`	Requests with variable durations	Open Source
`least_time`	Minimize latency by response time (advanced)	NGINX Plus

Testing and next steps

To validate any load-balancing configuration, run controlled load tests and monitor backend metrics (CPU, memory, connection counts, response times). Popular tools:

ab (ApacheBench) — simple HTTP load testing
wrk — multi-threaded HTTP benchmarking for higher concurrency
siege, hey — other lightweight tools

Example wrk command to generate load:

wrk -t4 -c100 -d30s http://example.com/

References:

NGINX documentation: https://nginx.org/en/docs/
NGINX Plus features: https://www.nginx.com/products/nginx/
wrk — https://github.com/wg/wrk

Now we’ll implement a few of these algorithms in practice to see how they behave under load.

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

Load-balancing algorithms supported by NGINX

Round Robin

Weighted Round Robin

Sticky sessions (`ip_hash`)

Least connections

Least time (NGINX Plus)

Quick comparison: which algorithm to choose

Testing and next steps

Watch Video

​Load-balancing algorithms supported by NGINX

​Round Robin

​Weighted Round Robin

​Sticky sessions (ip_hash)

​Least connections

​Least time (NGINX Plus)

​Quick comparison: which algorithm to choose

​Testing and next steps

Watch Video

Load-balancing algorithms supported by NGINX

Round Robin

Weighted Round Robin

Sticky sessions (`ip_hash`)

Least connections

Least time (NGINX Plus)

Quick comparison: which algorithm to choose

Testing and next steps