Why Load Balancing Matters
Load balancing distributes incoming client requests across multiple upstream servers so no single backend becomes a bottleneck or a single point of failure. In nginx, you declare a pool of backend servers inside an upstream block, then reference that pool by name in a proxy_pass directive; nginx then picks one member server per request according to whichever load-balancing algorithm the upstream block specifies. Beyond raw scaling, this also enables zero-downtime deployments, since you can mark one server down while it is being redeployed and nginx will simply route traffic to the remaining healthy members.
Cricket analogy: It's like a franchise splitting net-bowling duties across three bowling machines at training so no single machine overheats before a session ends, keeping every batter's practice uninterrupted.
Round Robin and Weighted Round Robin
upstream backend_pool {
server 10.0.0.11:8080 weight=3;
server 10.0.0.12:8080 weight=1;
server 10.0.0.13:8080 weight=1;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
}
}Round robin is nginx's default upstream algorithm: with no algorithm directive specified, requests are simply handed to each server in the upstream block in rotating order, giving every server an equal share over time. When backend servers have unequal capacity, weighted round robin lets you bias that rotation with a weight parameter on each server line — a server with weight=3 receives roughly three times as many requests as a server with the default weight=1, without changing the underlying round-robin rotation logic.
Cricket analogy: It's like a bowling attack rotating overs strictly by the batting order listed on the team sheet, with a strike bowler like Bumrah given a heavier over count than a part-timer, reflecting greater capacity.
least_conn and ip_hash
The least_conn algorithm sends each new request to whichever upstream server currently has the fewest active connections, which handles uneven request duration far better than plain round robin — a server stuck processing several slow requests won't keep receiving new ones just because its turn came up. ip_hash instead computes a hash of the client's IP address to consistently pin that client to the same backend server across requests, which is essential for session-affinity scenarios where the backend keeps per-user state in local memory rather than a shared store.
Cricket analogy: least_conn is like a fielding coach sending the next catching drill to whichever fielder has finished their current set fastest, rather than strictly rotating turns regardless of how long each drill takes.
Choosing an Algorithm
Choosing among these algorithms is a tradeoff between simplicity and awareness of real backend state: round robin and weighted round robin require no runtime bookkeeping and work well when requests are roughly uniform in cost, least_conn adapts to genuinely variable request duration but requires nginx to track connection counts per worker, and ip_hash sacrifices even distribution for session stickiness. nginx Plus adds a least_time mode that factors in measured response latency as well as active connections, but the open-source build's three core algorithms cover the overwhelming majority of real-world reverse-proxy deployments.
Cricket analogy: It's like choosing between a fixed batting order and a situational one — a fixed order (round robin) is simple to plan, while sending in whoever is 'in form' (least_conn) requires constantly tracking each batter's current touch.
You can combine weight with least_conn or ip_hash — a server line's weight still biases selection within those algorithms, it just isn't the sole factor the way it is in plain round robin.
ip_hash can produce uneven load distribution if one client (or a large NATed office behind a single public IP) generates disproportionately more traffic than others, since every request from that IP is pinned to one server regardless of that server's current load.
- Round robin is nginx's default: requests rotate evenly across all upstream servers with no directive needed.
- Weighted round robin biases that rotation using the weight parameter on each server line.
- least_conn routes each request to the server with the fewest currently active connections, adapting to variable request durations.
- ip_hash pins a given client IP to the same backend server, providing session affinity for apps with local in-memory state.
- weight can be combined with least_conn and ip_hash, not just plain round robin.
- ip_hash can cause uneven load when many clients share one public IP, since they all pin to a single server.
- nginx Plus adds a latency-aware least_time algorithm not available in open-source nginx.
Practice what you learned
1. What is nginx's default upstream load-balancing algorithm when no algorithm directive is specified?
2. A server line has weight=3 while others default to weight=1. What does this mean under weighted round robin?
3. Which algorithm is best suited for backends where requests vary significantly in processing time?
4. Why would you choose ip_hash over round robin?
5. What is a known drawback of ip_hash?
Was this page helpful?
You May Also Like
Reverse Proxy Basics
Learn what a reverse proxy does, how nginx's proxy_pass directive rewrites request paths, and how to preserve client context with forwarded headers.
Upstream Servers and Health Checks
Configure nginx upstream pools with passive and active health checks, backup servers, and persistent keepalive connections.
Proxying WebSockets with Nginx
Configure nginx to correctly upgrade and proxy long-lived WebSocket connections, including timeouts and load-balancing considerations.
Related Reading
Related Study Notes in DevOps
Browse all study notesAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics