> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Load Balancer

> Explains NGINX load balancing methods, configuration examples, and health check behavior to distribute traffic and improve performance and reliability across multiple servers.

A load balancer is a software (or hardware) component that distributes network traffic across multiple servers. It improves performance and reliability by sharing load and providing redundancy. Without a load balancer, a website relies on a single server—which may be acceptable for low traffic but quickly becomes a bottleneck as traffic grows. A single server is also a single point of failure: if it goes down, the site becomes unavailable.

One strong option for HTTP load balancing is NGINX. It provides flexible routing, multiple balancing algorithms, and built‑in failure handling to keep traffic flowing to healthy backends.

By default, NGINX performs passive health checks: when repeated connection failures or timeouts occur for a backend, NGINX marks that server unavailable and stops sending new requests to it. For active, configurable health checks, use NGINX Plus or third‑party modules.

![A diagram titled "Load Balancing With Nginx" showing users connecting through a network cloud to an NGINX load balancer which distributes traffic to multiple web servers. Health-check lines indicate some servers are healthy (green) while one shows failing status (red) with an alert.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-load-balancer-health-check-failure.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=099dc288a99ee4c98c2fcffedf8c77b1)

Because unhealthy backends are removed from rotation, users are not routed to servers that are down. If one or two servers fail, the website can stay online while you repair the affected machines.

Common NGINX load-balancing algorithms

* Round Robin — default. Distributes requests sequentially across the backend pool.
* Weighted Round Robin — assigns different weights so stronger servers receive more requests.
* IP Hash (sticky sessions) — routes requests from the same client IP to the same backend.
* Least Connections — picks the backend with the fewest active connections.
* Least Time — (NGINX Plus) chooses the backend with the lowest estimated response time.

Below are explanations, diagrams, and configuration examples for each algorithm.

Algorithms: Round Robin

Round Robin distributes requests in turn across the backend pool: request 1 → server A, request 2 → server B, request 3 → server C, then back to server A. Use it when backend servers have similar capacity and host the same content.

![A diagram titled "Algorithms: Round Robin" showing an NGINX load balancer using a round‑robin method to distribute requests to three numbered web servers. Arrows indicate sequential routing of traffic to servers 1, 2, and 3.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-round-robin-3-servers.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=c611883eb21946dbf4c7063562423c4b)

Define an upstream pool and reference it with `proxy_pass`. Upstream blocks must live in the `http` context (or in a file included by `nginx.conf`).

Example Round Robin upstream and proxy configuration:

```nginx theme={null}
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/;
    }
}
```

It’s common to place the `upstream` definition in the same file that references it for readability, but you can also include it from a separate file.

Weighted Round Robin

Weighted Round Robin behaves like Round Robin but lets you assign different weights to backends so some servers receive a larger share of requests. Useful when hosts have different CPU/memory resources.

![A diagram titled "Algorithms: Weighted Round Robin" showing an NGINX load balancer sending traffic through a weighted round-robin algorithm to three web servers labeled with weights 4, 2, and 1. The graphic illustrates distributing requests proportionally to server weights.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-weighted-round-robin-diagram.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=11b2b9d7403f344905d3153c8fa8dc29)

Example weighted configuration (first server gets 4× the requests of the third, and 2× the requests of the second):

```nginx theme={null}
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)

When session state is stored locally on a backend (for example, in-memory shopping cart), you often want the same client to return to the same backend. NGINX’s `ip_hash` provides simple session affinity by mapping a client IP to a backend.

How it works: NGINX uses the client IP to select a server; subsequent requests from that IP go to the same backend while it remains healthy.

![A diagram titled "Algorithms: IP Hash" showing an NGINX load balancer using an IP-hash method to route requests. Arrows from an IP-location icon point to three web servers in a server pool.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-ip-hash-load-balancer-diagram.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=622bbccf1401ff4793f55faa7ef7a632)

Example using `ip_hash`:

```nginx theme={null}
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/;
    }
}
```

`ip_hash` has limitations: clients behind NAT will share the same IP (causing uneven distribution), and changes to the backend pool can remap IPs to different servers. For robust session persistence consider client cookies, a shared session store (Redis), or sticky cookie modules.

Least Connections

The `least_conn` algorithm sends each new request to the backend with the fewest active connections. This makes distribution fairer when connections have varying durations (e.g., long polling or streaming).

![A diagram titled "Algorithms: Least Connection" showing an NGINX load balancer using the least-connection method to route traffic to one of several web servers. Arrows from the load balancer point to three servers (labeled 2, 5, 4), indicating it sends requests to the server with the fewest active connections.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-least-connection-load-balancer.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=c73283d3933ae860d3f45f6ef2b65b52)

Example:

```nginx theme={null}
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)

`least_time` selects the backend that is expected to return the full response the fastest, using response time metrics (for example, `last_byte` or `header`). This algorithm is available in NGINX Plus.

![A diagram showing an NGINX load balancer using a "Least Time" algorithm (stopwatch icon) to route traffic to multiple web servers. Arrows indicate requests being distributed from the load balancer/algorithm to three backend servers.](https://mintcdn.com/kodekloud-c4ac6d9a/ij3FNIPjp1w0Myd0/images/Nginx-for-Beginners/Intermediate-Config/Load-Balancer/nginx-least-time-load-balancer-diagram.jpg?fit=max\&auto=format\&n=ij3FNIPjp1w0Myd0\&q=85\&s=dcdff83cb225d7ebc0d91bda646383c7)

Example NGINX Plus configuration:

```nginx theme={null}
upstream backend {
    least_time last_byte/header;
    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/;
    }
}
```

With `least_time`, NGINX Plus evaluates which server can finish delivering the full response fastest, using timing metrics such as time to first byte or time to last byte based on the chosen options.

Quick comparison table

| Algorithm | When to use | Notes |
| - | - | - |
| Round Robin | Backends are homogeneous | Default, simple and efficient |
| Weighted Round Robin | Backends have different capacity | Assign `weight=` per server |
| `ip_hash` | Need simple session affinity | Limited with NAT; use cookies or shared store for reliability |
| `least_conn` | Requests have varying duration | Balances connection load rather than request count |
| `least_time` (Plus) | Optimize for fastest overall response | Requires NGINX Plus; uses response timing metrics |

Next steps

After learning the main algorithms (Round Robin, Weighted Round Robin, `ip_hash`, `least_conn`, and `least_time`), you can try implementing them in a staging environment and measure metrics such as response time, error rate, and connection distribution. For more advanced scenarios, explore active health checks, session persistence strategies, and NGINX Plus features.

References and further reading

* NGINX official docs: [https://nginx.org/en/docs/](https://nginx.org/en/docs/)
* NGINX Plus load balancing: [https://www.nginx.com/products/nginx/](https://www.nginx.com/products/nginx/)
* Session persistence strategies: consider cookie‑based affinity or centralized session stores (e.g., Redis) for scalable stateful applications.

> **[Watch Video](https://learn.kodekloud.com/user/courses/nginx-for-beginners/module/c78ff9cb-c15d-4f85-92fc-abee5ed98b20/lesson/4356e2fa-9121-4fb3-9d11-8b96f964df6c)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.