Nginx Load Balancing Algorithms, Scheduling States, and Configuration

Nginx Load Balancing Algorithms

1. Round‑robin (default) : Requests are distributed sequentially across backend servers; if a server crashes it is automatically removed from the pool.

2. Weight : Servers with larger weight values receive a higher proportion of traffic, useful when backend capacities differ or when distinguishing master and slave nodes.

3. ip_hash : Requests are assigned based on the hash of the client IP, ensuring a given IP always reaches the same backend server, which helps with session persistence for dynamic pages.

4. fair : An intelligent algorithm that considers page size and response time, directing traffic to servers with shorter response times; it requires the external upstream_fair module because Nginx does not support it natively.

5. url_hash : Distributes requests according to the hash of the requested URL, directing each URL to a specific backend server to improve cache efficiency; this also requires an additional Nginx hash module.

Nginx Load Balancing Scheduling States

In the upstream block you can set the status of each backend server:

• down : The server is temporarily excluded from load balancing. • backup : A standby server that receives traffic only when all non‑backup servers are unavailable or overloaded. • max_fails : The number of allowed request failures before the server is considered unavailable (default is 1). • fail_timeout : The period to wait before retrying a server after it has reached the max_fails limit.

Nginx Load Balancing Configuration Example

To enable load balancing, add an upstream block in the HTTP section of the Nginx configuration file. The example uses two real servers with IPs 192.168.1.209 and 192.168.1.250 , each running Nginx as a backend web server. The original article includes two illustrative screenshots of the configuration (shown as images below).

Nginx’s load balancing operates at layer 7 (application layer) and includes basic health checks limited to port probing. It performs well for small clusters (up to about ten servers). Compared with LVS, which works at layer 4 (transport layer) and offers higher performance, higher availability, and greater throughput for large‑scale deployments.