Configuring NGINX Round Robin Load Balancing for Backend Application Clusters

The Challenge: Distributing Traffic Across Multiple Backends

When a single application server reaches its resource limit, adding more hardware is the standard solution. However, the client needs a single entry point to access these servers. Without a load balancer, you must manually manage DNS or provide multiple IP addresses to users, which is impractical.

The solution is an NGINX reverse proxy using a Round Robin algorithm. This method distributes incoming requests sequentially across a list of backend servers, ensuring no single node is overwhelmed while providing a seamless experience to the end user.

Prerequisites

• NGINX installed (Version 1.14+ recommended) on a Linux-based controller node.
• Two or more backend application servers reachable via IP or hostname from the NGINX node.
• Root or sudo privileges on the NGINX controller to modify configuration files and reload the service.
• Network connectivity allowing traffic on the specific ports used by your application (e.g., port 80 or 8080).

Implementation Procedure

1. Define the Upstream Group

The upstream block tells NGINX which servers belong to the cluster. By default, NGINX uses Round Robin if no other method (like least_conn) is specified.

# Edit /etc/nginx/nginx.conf or a file in /etc/nginx/conf.d/
upstream app_cluster {
    server 10.0.0.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
}

Key Parameters:

• max_fails: The number of unsuccessful attempts to communicate with the server before it is marked unavailable.
• fail_timeout: The duration the server remains marked unavailable before NGINX attempts to send traffic to it again.

2. Route Traffic via Proxy Pass

Now, link the upstream group to a specific URL path using the proxy_pass directive inside a server block.

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

    location / {
        proxy_pass http://app_cluster;

        # Preserve client identity
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Critical Note: Without the proxy_set_header directives, your backend application will see the NGINX server's IP address for every request instead of the actual client's IP, breaking logs and geo-location features.

3. Apply and Validate Configuration

Run the following commands on the NGINX controller node to apply changes without dropping active connections:

# Check for syntax errors
sudo nginx -t

# If 'syntax is ok', reload the service
sudo systemctl reload nginx

Verification and Testing

Confirming Traffic Distribution

To verify that Round Robin is functioning, use a loop with curl from an external machine. If your backend servers return their own hostname or IP in the response, you should see the results rotate.

# Run 6 requests to see the rotation across 3 servers
for i in {1..6}; do curl http://app.example.com/; echo ""; done

Expected Result: The output should cycle through Server A, Server B, Server C, then back to Server A.

Testing Passive Health Checks

NGINX performs passive health checks. To test this, manually stop the application service on one backend node (e.g., sudo systemctl stop my-app). Run the curl loop again. NGINX should detect the failure and automatically route all traffic to the remaining healthy nodes without returning a 502 error to the client.

Comparison: Round Robin vs. Weighted Round Robin

Feature	Standard Round Robin	Weighted Round Robin
Traffic Split	Equal distribution (1:1:1)	Proportional distribution (e.g., 3:1:1)
Hardware Use Case	Identical server specs	Mixed server specs (Heterogeneous)
Configuration	server ip:port;	server ip:port weight=3;

Limitations and Recovery

Limitations: Round Robin does not account for current server load or session persistence. If your application requires a user to stay on the same server (Sticky Sessions), you must add the ip_hash directive inside the upstream block.

Rollback Procedure

If the new configuration causes instability or connectivity issues, revert to the previous known-good state:

1. Restore the backup of nginx.conf or the specific site configuration file.
2. Run sudo nginx -t to ensure the restored file is valid.
3. Run sudo systemctl reload nginx to apply the rollback.