Nginx is one of the most viable (and visible) open-source HTTP servers competing against Apache today. Due to its asynchronous, event-based nature, Nginx is highly scalable and can far outperform Apache under very heavy loads. As a result, it is one of the best choices to use when setting up a reverse proxy and/or load balancer, especially since it also now supports proxying of the WebSocket protocol.

Both functions are built into nginx (the Proxy module and Upstream module, respectively), so just about any installation of Nginx can be readied without additional software. The magic all happens in the nginx.conf file, by configuring the two modules (it doesn’t really matter which comes first) under the HTTP context.


Nginx Upstream

The Upstream module configuration defines the reverse proxy or load-balancing server(s), as well as the methods by which load balancing is conducted and the weight given to each server (by default, servers have a weight of 1). You can also configure how many times a server fails prior to skipping it (max_fails, defaults to 1), and how long before you try a failed server again (fail_timeout, defaults to 10 seconds, also used by max_fails to determine how long before the failure limit resets itself). You can also define a secondary server (backup) which will be used when all primary servers are down.

upstream load_balancing_group_1 {
 # optional, specifies that the least-busy server should be selected
 # least_conn;
 # optional, specifies that a hash of the IP should be used, enables session persistence
 # ip_hash;
 server esther.example.tld weight=3;
 server max_fails=5 fail_timeout=30;
 # optional, defines a backup server when all others fail
 server joshua.example.tld backup;

Note that the least_conn and ip_hash load balancing directives are mutually exclusive. In addition, when using ip_hash, you can optionally specify that one (or more) of the load-balancing servers is not operational long-term (add down after the server name) – but not the max_fails or fail_timeout directives.


Nginx Proxy

The Nginx Proxy module configuration can be used to turn Nginx into both a reverse as well as a forward (standard) proxy. Both are done using the proxy_pass directive in the location context.

location / {
    # optional, for use with forward proxying
    # resolver
    proxy_pass http://load_balancing_group_1;

Other similar directives exist as well, including proxying for FastCGI, uwsgi, SCGI, or memcached.

While there are more complex options available, and still far more options if you use the commercial version, NGINX Plus, the above covers the following use cases.

Forward proxy server

  • To enable consumption of IP geo-restricted content (by locating the Nginx server within the appropriate location)
  • If using SSL/TLS, allow access to blocked sites
  • Improve speeds to frequently-used sites if WAN connection is slow (as Nginx can cache proxied content)

Reverse proxy server

  • As part of a layered defence against attacks on your *real* server (by allowing only the Nginx server to access it)
  • Redirect traffic to a secondary server while the main server undergoes replacement, maintenance or testing
  • To balance the load between multiple, possibly geographically disparate servers, configured either identically or differently


For further reading after this brief introduction to the Nginx proxy and load-balancing functionality, try the Nginx tag.

This is a guest post by Marcus Lyons.

%d bloggers like this: