NGINX MasterClass: NGINX Server & Custom Load Balancer

 

Introduction

In the dynamic world of web development and infrastructure, speed, reliability, and scalability are paramount. One tool that consistently meets these demands is NGINX. Initially released as a web server optimized for performance, NGINX has since evolved into a full-fledged, feature-rich reverse proxy, load balancer, and HTTP cache.

This blog is a deep dive into mastering NGINX—from understanding its core architecture to building a custom load balancer that powers modern, high-availability applications.

Whether you're an aspiring DevOps engineer, a backend developer, or a systems architect, this NGINX masterclass will help you gain real-world expertise.

---

What is NGINX?

NGINX (pronounced "engine-x") is an open-source web server software that is known for its high performance, stability, and low resource consumption. It's commonly used for:

• Serving static content

• Reverse proxying and load balancing

• Handling SSL/TLS termination

• Caching HTTP responses

• Media streaming

Its event-driven, asynchronous architecture makes it an ideal choice for serving high-traffic websites and APIs.

---

Architecture of NGINX

Understanding NGINX’s architecture is essential before diving into custom configurations or building a load balancer.

NGINX uses a master-worker model:

• Master Process: Responsible for managing worker processes. It reads configuration files and maintains privileged operations.

• Worker Processes: Handle the actual client requests. These are event-driven and non-blocking, allowing NGINX to handle thousands of simultaneous connections with low memory consumption.

Each worker process handles multiple connections using a single thread via the epoll (Linux), kqueue (BSD/macOS), or select (Windows) system calls.

---

Installing NGINX

Installation steps vary by OS. On most Unix systems, installation is straightforward.

Ubuntu/Debian:

bash
sudo apt update
sudo apt install nginx

CentOS/RHEL:

bash
sudo yum install epel-release
sudo yum install nginx

macOS (via Homebrew):

bash
brew install nginx

Once installed, the default configuration file is located at /etc/nginx/nginx.conf.

---

NGINX Configuration Basics

NGINX uses a hierarchical configuration format. A typical configuration includes:

nginx
events {
    worker_connections 1024;
}

http {
    server {
        listen 80;
        server_name example.com;

        location / {
            root /var/www/html;
            index index.html;
        }
    }
}

• events: Sets event-driven configuration.

• http: Enables HTTP configuration.

• server: Defines server blocks (similar to virtual hosts in Apache).

• location: Configures routing rules.

---

Serving Static Content with NGINX

A common use case for NGINX is serving static files such as HTML, CSS, JS, or images.

Sample Configuration:

nginx
server {
    listen 80;
    server_name mysite.com;

    location / {
        root /var/www/mysite;
        index index.html;
    }
}

Place your static files in /var/www/mysite and access your website via http://mysite.com.

---

Reverse Proxy with NGINX

NGINX excels as a reverse proxy, sitting between client requests and backend services.

Basic Reverse Proxy Example:

nginx
server {
    listen 80;
    server_name api.mysite.com;

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

This forwards client requests to a backend app (e.g., a Flask or Node.js server on port 5000).

---

Load Balancing with NGINX

Load balancing distributes incoming traffic across multiple backend servers to improve reliability and scalability.

Types of Load Balancing:

• Round Robin (default)

• Least Connections

• IP Hash

Round Robin Example:

nginx
http {
    upstream backend {
        server 192.168.1.101;
        server 192.168.1.102;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
        }
    }
}

Each request is sent to a different backend in sequence.

---

Advanced Load Balancing: Least Connections and IP Hash

Least Connections:

Sends traffic to the server with the fewest active connections.

nginx
upstream backend {
    least_conn;
    server 192.168.1.101;
    server 192.168.1.102;
}

IP Hash:

Routes based on client IP. Ensures session persistence.

nginx
upstream backend {
    ip_hash;
    server 192.168.1.101;
    server 192.168.1.102;
}

---

Health Checks for Backends

NGINX Plus supports active health checks, but for open-source NGINX, we use passive checks and third-party modules.

Passive Check Example:

NGINX automatically marks a server as unavailable if it fails to respond.

nginx
upstream backend {
    server 192.168.1.101 max_fails=3 fail_timeout=30s;
    server 192.168.1.102;
}

---

SSL Termination with NGINX

SSL termination offloads the HTTPS processing from backend servers.

Steps to Set Up SSL:

1. Obtain an SSL certificate (e.g., via Let's Encrypt).

2. Update your server block:

nginx
server {
    listen 443 ssl;
    server_name mysite.com;

    ssl_certificate /etc/nginx/ssl/mysite.crt;
    ssl_certificate_key /etc/nginx/ssl/mysite.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Redirect HTTP to HTTPS:

nginx
server {
    listen 80;
    server_name mysite.com;
    return 301 https://$host$request_uri;
}

---

Creating a Custom Load Balancer

Let’s build a custom load balancer using NGINX’s configuration flexibility and Lua scripting (via the ngx_http_lua_module).

Step 1: Enable Lua Module (Optional)

You’ll need to compile NGINX with Lua support or install OpenResty (an NGINX variant with Lua built-in).

Step 2: Define Upstream Pool with Custom Logic

Let’s simulate a weighted round robin with custom Lua code:

nginx
http {
    lua_shared_dict servers 10m;

    init_worker_by_lua_block {
        local dict = ngx.shared.servers
        dict:set("192.168.1.101", 5)
        dict:set("192.168.1.102", 1)
    }

    server {
        listen 80;

        location / {
            content_by_lua_block {
                local dict = ngx.shared.servers
                local ip1 = "192.168.1.101"
                local ip2 = "192.168.1.102"

                -- Simple logic: Choose based on weight
                local rand = math.random(1, 6)
                local backend = (rand <= 5) and ip1 or ip2

                ngx.exec("@proxy", { backend = backend })
            }
        }

        location @proxy {
            internal;
            proxy_pass http://$arg_backend;
        }
    }
}

This simulates a weighted load balancer, routing ~5 out of 6 requests to server 1.

---

Caching with NGINX

NGINX can cache upstream responses, reducing load on backend servers.

Enable Basic Caching:

nginx
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g;

server {
    location / {
        proxy_cache my_cache;
        proxy_pass http://backend;
        proxy_cache_valid 200 1h;
    }
}

This caches HTTP 200 responses for 1 hour.

---

Rate Limiting

Rate limiting helps prevent abuse and DoS attacks.

nginx
http {
    limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;

    server {
        location / {
            limit_req zone=req_limit burst=20;
            proxy_pass http://backend;
        }
    }
}

This allows 10 requests per second per IP, with a burst capacity of 20.

---

Security Best Practices

To harden your NGINX deployment:

• Use the latest stable version.

• Disable server tokens:

  nginx
  server_tokens off;
  

• Limit request methods and size:

  nginx
  client_max_body_size 1m;
  limit_except GET POST { deny all; }
  

• Enable headers for security:

  nginx
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Content-Type-Options "nosniff";
  

---

Monitoring and Logging

NGINX logs access and error data by default.

• Access Logs: /var/log/nginx/access.log

• Error Logs: /var/log/nginx/error.log