What is the difference between Nginx load balancer and reverse proxy?

A reverse proxy forwards requests to a single backend server, while a load balancer is a reverse proxy with multiple upstream servers and an algorithm to distribute requests among them. Both use the same Nginx proxy_pass directive — the difference is whether you define one backend or several in the upstream block.

Can I use Nginx load balancing with HTTPS?

Yes. The most common production setup is SSL Termination: Nginx handles HTTPS from clients and forwards plain HTTP internally to backends. This removes the need to manage certificates on each backend server. You can use Let's Encrypt with Certbot to get a free certificate for the load balancer.

How many backend servers can Nginx load balance?

There is no hard limit. You can add as many server lines as needed inside the upstream block. A typical setup starts with 2–3 backends and scales horizontally as traffic grows. Weights and max_fails can be tuned per server.

Does Nginx open source support active health checks?

Nginx open source supports passive health checks only — if a backend returns errors above the max_fails threshold it is temporarily removed from rotation. Active health checks (probing backends at intervals) require Nginx Plus or a module like nginx_upstream_check_module compiled from source.

Configure Nginx as Load Balancer for Multiple Backends on VPS

When traffic grows beyond what a single server can handle, a load balancer becomes essential. Nginx includes production-grade load balancing built in — no extra software required. This guide walks through configuring Nginx as a load balancer on VPS Ubuntu to distribute requests across multiple backend servers.

How Load Balancing Works

A load balancer sits in front of backend servers, receiving requests from clients and forwarding them to the most suitable backend. Benefits include handling more traffic, eliminating single points of failure, and enabling zero-downtime deployments.

Round-Robin

Rotates requests evenly across all servers. Best when backends have identical specs.

Least Connection

Sends each new request to the server with the fewest active connections. Best for long-running requests.

IP Hash

Same client IP always routes to the same backend. Best for apps requiring sticky sessions.

Architecture Overview

In this example, a VPS running as the Load Balancer (IP: 10.0.0.1) accepts traffic on ports 80/443 and distributes it to two backend servers (10.0.0.2 and 10.0.0.3) running your application on port 8080.

Install Nginx on the Load Balancer VPS

sudo apt update && sudo apt install -y nginx
sudo systemctl enable nginx

Configure Upstream and Load Balancing

Create a new configuration file:

sudo nano /etc/nginx/sites-available/loadbalancer

Add this configuration (Round-Robin):

# Define the backend server pool
upstream backend_pool {
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
    # keepalive improves performance
    keepalive 32;
}

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        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;
    }
}

Switching to Least Connection

upstream backend_pool {
    least_conn;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

Switching to IP Hash (Sticky Sessions)

upstream backend_pool {
    ip_hash;
    server 10.0.0.2:8080;
    server 10.0.0.3:8080;
}

Weighted Distribution for Different Server Specs

upstream backend_pool {
    server 10.0.0.2:8080 weight=3;  # receives 3/4 of traffic
    server 10.0.0.3:8080 weight=1;  # receives 1/4 of traffic
}

Enable Configuration and Test

sudo ln -s /etc/nginx/sites-available/loadbalancer /etc/nginx/sites-enabled/
sudo nginx -t          # verify config syntax
sudo systemctl reload nginx

Tuning Timeouts and Buffers for Production

Properly tuning proxy timeouts and buffer settings prevents failed requests when backends are slow or responses are large. Add these directives inside the location / block or at the server level.

location / {
    proxy_pass http://backend_pool;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    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;

    # Timeout settings
    proxy_connect_timeout 5s;
    proxy_send_timeout    60s;
    proxy_read_timeout    60s;

    # Buffer settings — tune for your response sizes
    proxy_buffering on;
    proxy_buffer_size       16k;
    proxy_buffers           8 16k;
    proxy_busy_buffers_size 32k;
}

For low-latency API endpoints that return small responses, you can disable buffering with proxy_buffering off; — but this increases load on Nginx worker processes, so benchmark before applying globally.

SSL/TLS Termination on the Load Balancer

The most common production approach is SSL Termination: the load balancer handles HTTPS from clients and forwards plain HTTP internally to backend servers. Backends no longer need certificates, reducing overhead and simplifying certificate management.

# Obtain a free certificate with Certbot first
sudo certbot --nginx -d yourdomain.com

# HTTPS server block
server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto https;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

Rate Limiting to Protect Against Traffic Spikes

Because the load balancer is the single entry point for all traffic, it is the ideal place to enforce rate limiting. This protects backend servers from traffic spikes, brute-force attacks, and excessive scraping without touching application code.

# Define zone in the http{} block (nginx.conf or conf.d/)
http {
    limit_req_zone $binary_remote_addr zone=general:10m rate=30r/m;
    limit_req_zone $binary_remote_addr zone=login:10m   rate=5r/m;
}

# Apply per endpoint
location /api/auth/ {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://backend_pool;
}

location / {
    limit_req zone=general burst=50 nodelay;
    proxy_pass http://backend_pool;
}

Rate	Recommended For	Notes
10r/s	General API	Moderate restriction
1r/s	Login endpoint	Strict — prevents brute-force
100r/s	Static assets	Loose — public resources

Passive Health Checks

Nginx Open Source supports passive health checks automatically — if a backend consistently returns errors, Nginx temporarily removes it from the pool:

upstream backend_pool {
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:8080 max_fails=3 fail_timeout=30s;
}

Note: Active Health Checks (probing backends every N seconds) require Nginx Plus (commercial) or Nginx + Lua. For open-source active health checking, consider HAProxy as an alternative.

Next Steps After Your Load Balancer Is Running

Once Nginx is distributing traffic successfully, a few more steps will make your setup production-ready and maintainable long-term.

Enable SSL/TLS: Use Let's Encrypt and Certbot to obtain a free certificate for the load balancer and redirect all HTTP traffic to HTTPS automatically.
Set up monitoring: Use Uptime Kuma, Prometheus, or a similar tool to track uptime and latency for both the load balancer and each individual backend. Set alerts for error rate spikes and backend failures.
Configure log rotation: Prevent access logs from filling the disk by setting up logrotate to rotate daily and retain 30 days of history.
Test failover regularly: Simulate backend failure by stopping one server and confirming that traffic continues flowing through the remaining backends. Run this test after every config change.
Plan rolling deployments: Use a script or tool like Ansible to deploy updates to backends one at a time while the load balancer keeps the others in rotation — this achieves zero-downtime deploys without extra infrastructure.

Nginx load balancing on a VPS is one of the most cost-effective ways to build a high-availability architecture. The software is open source with no licensing cost, and it can handle very high request volumes on modest hardware. AsiaGB VPS with full root access lets you configure Nginx exactly to your requirements with no restrictions from the hosting provider.

Monitor the Load Balancer

sudo nginx -t && sudo systemctl status nginx
# Watch access log in real time
sudo tail -f /var/log/nginx/access.log

VPS for High-Traffic Applications at AsiaGB

AsiaGB VPS runs Linux Ubuntu/Debian with full root access — configure Nginx load balancing exactly as needed. Plans from 500 THB/month.

View VPS Plans