Unveiling Nginx Load Balancing: Deep Dive into Strategies and Real‑World Tests

Introduction

Load balancing remains a timeless topic. While hardware appliances such as F5 BIG‑IP, Citrix NetScaler, and Radware can solve load issues, their high cost makes software solutions the preferred choice for many Internet companies. Nginx, with its excellent reverse‑proxy capabilities and flexible load‑balancing policies, is widely adopted.

As website traffic grows, load balancing (distributing traffic across multiple service units) ensures high availability, fast response times, and a good user experience.

Nginx’s first public release was in 2004, with version 1.0 released in 2011. Its high stability, powerful features, and low resource consumption have made it a strong competitor to Apache, especially for its load‑balancing functionality.

This article examines Nginx’s load‑balancing strategies from source‑code perspective and practical industrial cases, comparing each strategy to provide guidance for Nginx users.

Source‑Code Analysis

Nginx’s load‑balancing strategies are divided into two categories: built‑in strategies and extended strategies.

Built‑in strategies include weighted round‑robin and IP‑hash , compiled into the Nginx core by default and enabled via configuration parameters. Extended strategies such as fair , generic hash , and consistent hash are not compiled by default.

Because the core load‑balancing code has not changed fundamentally across Nginx versions, the analysis uses the stable nginx‑1.0.15 source as an example.

Weighted Round Robin

The processing flow for a request is illustrated below:

Key points:

The algorithm first performs a depth‑first search: it assigns requests to the highest‑weight server until its weight drops below the next server’s weight, then moves to the next server.

If all backend servers are down, Nginx resets the status flags to avoid a complete timeout.

The relevant source files are ngx_http_upstream_round_robin.c and ngx_http_upstream_round_robin.h. Important declarations include current_weight (dynamic during request handling) and weight (static configuration value).

A bitmap named tried records whether a server has already been attempted. For fewer than 32 servers, a single int suffices; otherwise memory is allocated from the pool.

The actual strategy implementation consists of about 30 lines of straightforward code:

IP‑Hash Strategy

IP‑hash is another built‑in strategy with a flow similar to round‑robin but with a different algorithm. The processing diagram is:

The core implementation is shown below:

The hash value depends on both the client IP and the number of backend servers. After 20 unsuccessful attempts to find a usable server, the algorithm falls back to round‑robin, effectively making IP‑hash a variant of round‑robin.

Because the hash is deterministic, two identical IPs will always map to the same server, which can cause imbalance if certain IPs generate far more traffic.

Fair Strategy

Fair is an extended strategy (not compiled by default) that selects the backend with the lowest response time, providing strong adaptability but requiring careful testing in complex network environments.

Generic Hash and Consistent Hash

Both are extended strategies. Generic hash can use any Nginx variable as the key, while consistent hash employs Nginx’s built‑in hash ring and supports memcached.

Comparative Testing

Four test scenarios were executed using two tools: easyABC (a Baidu‑internal load‑testing tool) and polygraph (an open‑source performance tester). The test environment consisted of five physical machines: one 8‑core server running Nginx, and four 4‑core machines for the test tools and stub web servers.

Key metrics:

Balance : Even distribution of requests across backends.

Consistency : Same key always maps to the same server.

Fault tolerance : Ability to continue operating when some backends fail.

Scenarios:

All servers healthy.

Server 4 down.

Servers 3 and 4 down.

All servers restored.

Results showed that weighted round‑robin performed well in balance and fault tolerance, while the fair strategy exhibited large fluctuations due to its adaptive nature. Generic and consistent hash suffered traffic loss when a backend failed, whereas IP‑hash did not lose traffic but showed poor balance because high‑traffic IPs dominate.

Real‑world traffic analysis confirmed that IP‑hash’s reliance on client IP leads to severe imbalance when a few IP prefixes generate disproportionate traffic.

Conclusion

Through source‑code inspection and extensive performance testing, we evaluated Nginx’s load‑balancing strategies in terms of balance, consistency, fault tolerance, and suitable application scenarios. No single strategy fits all cases; the optimal choice depends on the specific environment and the operator’s familiarity with the algorithm.

We hope this analysis and the accompanying data help developers and operations engineers select the most appropriate load‑balancing method for their workloads.