Which Nginx Load‑Balancing Strategy Wins in Production? A Real‑World Guide

Real‑World Incident

During a major sales event, an e‑commerce system lost shopping‑cart data because the Nginx load‑balancing strategy was misconfigured. Symptoms included disappearing cart items, unstable login sessions, and highly uneven server CPU usage.

Core Knowledge: Two Main Strategies

1. Weighted Round‑Robin

How it works : Distributes requests proportionally according to server weights.

upstream backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 weight=1;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Applicable scenarios :

Servers have clearly different performance.

Stateless applications such as APIs.

Need flexible traffic distribution.

2. IP Hash

How it works : Uses a hash of the client IP to consistently route a request to the same backend server.

upstream backend {
    ip_hash;
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Applicable scenarios :

Stateful applications that require session stickiness.

Systems that rely heavily on local cache.

Practical Comparison Test

A week‑long stress test was run on three identical servers using both strategies. Results showed Weighted Round‑Robin achieved lower average response time (156 ms vs 189 ms), higher throughput (8,432 RPS vs 7,156 RPS), and better load distribution, while IP Hash provided better session consistency.

Production Best Practices

Solution 1: Mixed Strategy (Recommended)

# Static resources use weighted round‑robin
upstream static_backend {
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
}
# User‑related APIs use IP hash
upstream user_backend {
    ip_hash;
    server 192.168.1.20:8080;
    server 192.168.1.21:8080;
}
server {
    listen 80;
    server_name example.com;
    # Static assets
    location ~* \.(css|js|png|jpg|jpeg|gif|ico)$ {
        proxy_pass http://static_backend;
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    # User APIs
    location /api/user/ {
        proxy_pass http://user_backend;
        proxy_set_header Host $host;
    }
    # Other APIs
    location /api/ {
        proxy_pass http://static_backend;
        proxy_set_header Host $host;
    }
}

Solution 2: Dynamic Weight Adjustment

# Monitor script: adjust weights based on CPU load
#!/bin/bash
while true; do
    for server in server1 server2 server3; do
        cpu_usage=$(ssh $server "top -bn1 | grep 'Cpu(s)' | awk '{print $2}' | cut -d'%' -f1")
        if [ $cpu_usage -lt 30 ]; then
            weight=3
        elif [ $cpu_usage -lt 70 ]; then
            weight=2
        else
            weight=1
        fi
        # Update Nginx config accordingly (omitted)
    done
    sleep 30
done

Common Pitfalls

Pitfall 1: Blindly Using IP Hash

Wrong configuration (e.g., behind a CDN):

upstream backend {
    ip_hash; # using IP hash behind CDN
    server web1:8080;
    server web2:8080;
}

All requests appear from the same IP, causing severe load imbalance.

Correct approach :

upstream backend {
    hash $http_x_forwarded_for consistent; # use real client IP
    server web1:8080;
    server web2:8080;
}

Pitfall 2: Improper Weight Settings

New servers were three times faster but only given double weight, leaving them idle while old servers were overloaded.

upstream backend {
    server old_server:8080 weight=1;
    server new_server:8080 weight=4; # set according to actual performance
}

Performance Tuning Tips

1. Enable Keep‑Alive Connections

upstream backend {
    server 192.168.1.10:8080 weight=3;
    keepalive 32; # maintain 32 persistent connections
}
server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

2. Health Check Configuration

upstream backend {
    server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=10s;
    server 192.168.1.11:8080 weight=2 max_fails=2 fail_timeout=10s;
}

3. Monitoring Script

# nginx_status.sh – real‑time upstream health check
#!/bin/bash

echo "=== Nginx Upstream Status ==="
curl -s http://localhost/nginx_status | grep -A 20 "upstream"

echo "=== Backend Health Check ==="
for server in 192.168.1.10 192.168.1.11; do
    response=$(curl -o /dev/null -s -w "%{http_code}
" http://$server:8080/health)
    if [ $response -eq 200 ]; then
        echo "✅ $server - OK"
    else
        echo "❌ $server - Failed ($response)"
    fi
done

Summary & Recommendations

Stateless applications should prefer Weighted Round‑Robin for better performance and scalability.

Stateful applications must use IP Hash cautiously , preferably with external session stores like Redis.

Mixed strategies are optimal : apply different load‑balancing methods per business scenario.

Continuous monitoring is essential : regularly analyze access logs and performance metrics.