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.
【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.
Open Source Linux
Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
