Operations 10 min read

Master Nginx Load Balancing: Algorithms, Reverse Proxy & Config Examples

This guide explains how Nginx functions as a load balancer and reverse proxy, covering its event‑driven architecture, worker processes, and core mechanisms, and details common balancing algorithms such as round‑robin, least connections, IP hash, weighted round‑robin and weighted least connections with full configuration examples and monitoring commands.

Open Source Linux
Open Source Linux
Open Source Linux
Master Nginx Load Balancing: Algorithms, Reverse Proxy & Config Examples

【Nginx】Load Balancing

Nginx acts as a load balancer by distributing requests to multiple backend servers, improving performance, reliability, and scalability. It supports various algorithms such as round‑robin, least connections, IP hash, weighted round‑robin, and weighted least connections.

1. Working Principle

Nginx achieves high performance through an event‑driven, non‑blocking architecture that leverages the operating system's multiplexing mechanisms, allowing a single thread to handle many concurrent connections without thread switching.

Event loop – The core loop processes events in a non‑blocking manner, waiting for notifications before handling each request, which maximizes CPU utilization.

Multi‑process – Nginx can spawn multiple worker processes via the worker_processes directive, each with its own event loop and isolated resources, enabling efficient use of multi‑core CPUs and improving reliability.

2. Reverse Proxy

server {
    listen 80;
    server_name example.com;
    root /root/build/; # static assets
    index index.html;

    location /api/server/ {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

The configuration sets a static root, defines a domain, and proxies requests matching /api/server/ to a backend service at http://localhost:8080, adding appropriate headers for host and client IP.

3. Load Balancing Algorithms

1. Round‑Robin

The default algorithm distributes requests sequentially across servers, which may not consider individual server load.

upstream tornado_servers {
    server 192.168.31.158:8888;
    server localhost:8888;
}

server {
    listen 80;
    server_name 192.168.62.132;

    location / {
        proxy_pass http://tornado_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.62.0/24;
        deny all;
    }
}

2. Least Connections

Requests are sent to the server with the fewest active connections, improving overall performance but still ignoring actual load.

upstream tornado_servers {
    least_conn;
    server 192.168.31.158:8888;
    server localhost:8888;
}

server {
    listen 80;
    server_name 192.168.62.132;
    location / {
        proxy_pass http://tornado_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.62.0/24;
        deny all;
    }
}

3. IP Hash

Clients are mapped to servers based on the hash of their IP address, preserving session affinity but preventing true load distribution for a single client.

upstream tornado_servers {
    ip_hash;
    server 192.168.31.158:8888;
    server localhost:8888;
}

server {
    listen 80;
    server_name 192.168.62.132;
    location / {
        proxy_pass http://tornado_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.62.0/24;
        deny all;
    }
}

4. Weighted Round‑Robin

Each server receives a weight value that influences how many requests it handles relative to others.

upstream tornado_servers {
    server 192.168.31.158:8888 weight=5;
    server localhost:8888 weight=3;
}

server {
    listen 80;
    server_name 192.168.62.132;
    location / {
        proxy_pass http://tornado_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.62.0/24;
        deny all;
    }
}

5. Weighted Least Connections

Combines connection count with weight to select the server with the lowest weighted load.

upstream tornado_servers {
    least_conn;
    server 192.168.31.158:8888 weight=5;
    server localhost:8888 weight=3;
}

server {
    listen 80;
    server_name 192.168.62.132;
    location / {
        proxy_pass http://tornado_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 192.168.62.0/24;
        deny all;
    }
}

4. Summary

Reverse proxy acts as a bridge between users and backend servers, forwarding requests while hiding server details, providing security and load‑balancing capabilities. Intelligent request distribution ensures balanced load across servers, enhancing performance and reliability for high‑concurrency scenarios.

Monitoring directives such as server accepts handled requests, Active connections, Reading, Writing, and Waiting provide real‑time statistics on connection counts and request handling.

operationsLoad BalancingNginxreverse proxy
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.