Nginx serves dual purposes in modern infrastructure: it functions as both a web server and a load balancing solution through reverse proxy capabilities. This article explores how to implemant load balancing effectively using Nginx.

Core Functions of Load Balancers

A load balancer acts as an intermediary layer between clients and backend servers, distributing incoming traffic across multiple servers. The primary benefits include:

• Traffic Distribution: When high volumes of concurrent users access an application, the load balancer distributes requests evenly across available backend servers, preventing any single server from becoming overwhelmed and potentially failing.
• Performance Enhancement: By spreading the load across multiple servers, the system can handle significantly higher concurrent connections while maintaining responsive user experiences.
• Scalability: Additional backend servers can be seamlessly integrated into the pool as traffic demands grow, without requiring changes to client-side configurations.
• High Availability: Backend servers operate redundantly—if one server fails, the load balancer automaticallly redirects traffic to healthy instances, ensuring continuous service availability.

Load Balancing Scheduling Algorithms

Nginx supports several scheduling algorithms, each suited to different use cases:

1. Round-Robin (RR)
The default algorithm that cycles through available servers sequentially. Nginx also supports weighted round-robin, where the weight parameter determines the proportion of requests each server receives. Servers with higher weight values accept more traffic. The default weight is 1 if not specified.

2. Least Connections
This algorithm routes new requests to the server with the fewest active connections, making it ideal for scenarios where connection lifetimes vary significantly across requests.

3. IP Hash
Using the client's IP address as the hashing key, this algorithm ensures that requests from the same client are consistently directed to the same backend server. This is particularly useful when session state is maintained server-side and sticky sessions are required.

Implementation: Setting Up Nginx Load Balancing

The following steps outline the process of configuring Nginx as a load balancer:

Step 1: Server Preparation

Prepare a dedicated server for the load balancer and perform initial system configuration as needed for your environment.

Step 2: Install Nginx

Install Nginx using your preferred method. For production environments, compiling from source provides greater flexibility in customization:

cd /usr/local/nginx-1.x.x/
./configure --prefix=/usr/local/nginx
make && make install

Step 3: Configure Load Balancing

Edit the Nginx configuration file located in the conf directory:

cd /usr/local/nginx/conf/
vim nginx.conf

The following configuration demonstrates a basic load balancing setup using the round-robin algorithm:

worker_processes  2;

events {
    worker_connections  2048;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # Define the upstream server pool
    upstream backend_pool {
        server 192.168.1.101;
        server 192.168.1.102;
    }

    server {
        listen       80;
        server_name  localhost;

        location / {
            # Forward incoming requests to the upstream pool
            proxy_pass http://backend_pool;
        }
    }
}

This configuration establishes an upstream block named backend_pool containing two backend servers. The proxy_pass directive within the location block redirects all incoming requests to this server pool.

Step 4: Validate Configuration

Before applying changes, verify the configuration syntax:

nginx -t

This command checks for syntax errors in the configuration file without actually reloading the service.

Step 5: Reload Nginx

Apply the configuration changes by reloading Nginx:

nginx -s reload

This gracefully reloads the configuration without interrupting active connections.

Testing Load Balancing Functionality

To verify proper operation, access the load balancer's IP address through a web browser and repeatedly refresh the page. Requests should alternate between the configured backend servers. Successful alternation between 192.168.1.101 and 192.168.1.102 confirms the load balancing setup is functioning correctly.

Understanding Request Flow and Client IP Preservation

The NAT Challenge

Backend servers receive requests originating from the load balancer's IP address rather than the actual client's IP. This occurs because Nginx performs Network Address Translation (NAT), replacing the source IP with its own address before forwarding requests to backend servers. This behavior is inherent in layer 7 (application layer) load balancing.

To address this limitation, Nginx can insert the original client IP into HTTP request headers using the X-Real-IP field. This allows backend applications to identify the actual client source.

Configuring Client IP Forwarding

Step 1: Modify Load Balancer Configuration
Add directives to the location block to preserve the client's original IP addres:

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://backend_pool;
}

Then validate and reload the configuration:

nginx -t
nginx -s reload

Step 2: Configure Backend Servers
Update each backend server's Nginx configuration to capture and utilize the X-Real-IP header value. This may involve logging configuration or passing the header to application code.

After making these changes, restart Nginx on all backend servers:

nginx -s reload

Advanced Routing: URL-Based Distribution

Nginx can route requests to different backend servers based on URL patterns. This capability enables sophisticated architectures where specific URL paths are directed to dedicated service clusters.

Configuration Example:

location /api/ {
    proxy_pass http://api_servers;
}

location /static/ {
    proxy_pass http://static_content_servers;
}

When implementing URL-based routing, ensure the target directories or paths exist on the respective backend servers. For instance, if directing traffic to 192.168.1.102 for /sc/ requests, verify that the sc directory and its contents (such as index.html) are present on that server's document root.

This approach supports microservices architectures and enables logical separation of different application components across dedicated server infrastructure.