Mastering Nginx: From Basics to Advanced Load Balancing and High‑Concurrency Techniques

What is Nginx?

Nginx is a lightweight, high‑performance reverse‑proxy web server supporting HTTP, HTTPS, SMTP, POP3 and IMAP, capable of handling tens of thousands of concurrent connections.

Advantages of Nginx

Cross‑platform and easy to configure.

Non‑blocking, high‑concurrency handling (2‑3 万 connections, up to 5 万 officially).

Low memory usage (10 workers ≈ 150 MB).

Open‑source and cost‑effective.

High stability with minimal downtime.

Built‑in health checks to avoid routing to failed back‑ends.

Typical Application Scenarios

Standalone HTTP server for static content.

Virtual hosting multiple sites on one machine.

Reverse proxy and load balancing for backend clusters.

API gateway and security management.

How Nginx Handles Requests

server {
    listen 80;                 # listening port
    server_name localhost;
    location / {
        root html;            # site root directory
        index index.html index.html;
    }
}

Master process parses configuration and creates listening sockets.

Worker processes are forked.

Workers accept new connections; the successful worker creates an ngx_connection_t structure.

Read/write event handlers are set and data exchange begins.

Connection is closed by client or Nginx.

High‑Concurrency Implementation

Nginx uses an asynchronous, non‑blocking event model (epoll). Workers become idle while waiting for I/O, allowing a few processes to serve massive concurrent requests.

Forward vs. Reverse Proxy

Forward proxy: client → proxy → origin server (proxy acts on behalf of the client).

Reverse proxy: client → proxy → internal server (proxy hides the origin server).

Nginx Directory Structure

# tree /usr/local/nginx
/usr/local/nginx
├── client_body_temp
├── conf                 # configuration files
│   ├── fastcgi.conf
│   ├── mime.types
│   └── nginx.conf       # main config
├── html                 # default site
│   ├── 50x.html
│   └── index.html
├── logs
│   ├── access.log
│   └── error.log
├── sbin
│   └── nginx            # executable
└── ...

Key Directives in nginx.conf

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;
    server {
        listen 80;
        server_name localhost;
        location / {
            root html;
            index index.html index.htm;
        }
        error_page 500 502 503 504 /50x.html;
        location = /50x.html { root html; }
    }
}

Cookie vs. Session

Both store user data as key‑value pairs.

Cookie: stored in the client browser, one per domain, editable by the user, set via HTTP response.

Session: stored on the server (file, DB, Redis), holds sensitive data, identified by a cookie key.

Why Nginx Does Not Use Multithreading

Apache creates a process or thread per request, consuming CPU and memory. Nginx uses a single‑threaded, asynchronous model (epoll) where workers handle many connections without per‑request threads, saving resources and reducing context switches.

Nginx vs. Apache

Nginx

Apache

Event‑driven, lightweight

Process‑driven

All requests handled by a few workers

One thread per request

Avoids child processes

Uses many child processes

Better performance under load

Performance degrades with many connections

Static‑Dynamic Resource Separation

Separate immutable static files (CSS, JS, images) from dynamic content (JSP, DO) so static assets can be cached (e.g., via CDN), reducing backend load and improving response speed.

What Is a CDN?

A Content Delivery Network places copies of content on edge servers close to users, reducing latency and bandwidth usage.

Implementing Static‑Dynamic Separation with Nginx

location /image/ {
    root /usr/local/static/;
    autoindex on;
}

Load‑Balancing Algorithms

Round Robin (default)

upstream backserver {
    server 1112;
    server 1113;
}

Weight

upstream backserver {
    server 1112 weight=2;
    server 1113 weight=8;
}

IP Hash

upstream backserver {
    ip_hash;
    server 1112:88;
    server 1113:80;
}

Fair (third‑party)

upstream backserver {
    server server1;
    server server2;
    fair;
}

URL Hash (third‑party)

upstream backserver {
    server squid1:3128;
    server squid2:3128;
    hash $request_uri;
    hash_method crc32;
}

Cross‑Domain Solution with Nginx

Proxy cross‑origin API requests through the same domain, then forward them to the real backend.

Virtual Host Configuration

Domain‑based, port‑based, and IP‑based virtual hosts can be defined using server_name and listen directives.

# Domain‑based virtual host
server {
    listen 80;
    server_name www.example.com;
    location / { root /data/www; index index.html; }
}

# Port‑based virtual host
server {
    listen 8080;
    server_name example.com;
    location / { root /data/www; }
}

The location Directive

Matches request URIs using exact, prefix, or regex patterns with defined priority.

location =/ { return 400; }
location ^~ /av { root /data/av/; }
location ~ /media { alias /data/static/; }
location ~* .*\\.(jpg|gif|png|js|css)$ { root /data/av/; }
location / { return 403; }

Rate Limiting (Leaky Bucket)

Normal request rate limiting

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;
server {
    location /seckill.html {
        limit_req zone=one;
        proxy_pass http://lj_seckill;
    }
}

Burst limiting

limit_req zone=one burst=5 nodelay;

Concurrent connection limiting

limit_conn_zone $binary_remote_addr zone=myip:10m;
server {
    location / {
        limit_conn myip 10;
        limit_conn myServerName 100;
    }
}

Leaky Bucket vs. Token Bucket

Leaky bucket drops excess requests when the outflow rate is lower than the inflow. Token bucket adds tokens at a constant rate; a request proceeds only if a token is available.

High Availability Configuration

server {
    listen 80;
    server_name www.example.com;
    location / {
        proxy_pass http://backServer;
        proxy_connect_timeout 1s;
        proxy_send_timeout 1s;
        proxy_read_timeout 1s;
    }
}

Blocking Specific IPs or Browsers

# Block a specific IP
if ($remote_addr = 11115) { return 403; }
# Block Chrome browsers
if ($http_user_agent ~ Chrome) { return 500; }

Rewrite Global Variables

$remote_addr        # client IP
$binary_remote_addr # binary client IP
$remote_port       # client port
$host              # request Host header
$request           # full request line
$request_uri       # URI with args
$uri               # URI without args
$status            # response status code

Backend Health Checks

Method 1: Use proxy_next_upstream and proxy_connect_timeout to detect failures. Method 2 (recommended): Compile nginx_upstream_check_module for active health checks.

Enabling Gzip Compression

http {
    gzip on;
    gzip_min_length 1k;
    gzip_comp_level 2;
    gzip_types text/plain application/javascript text/css application/xml image/jpeg image/gif image/png;
    gzip_vary on;
}

ngx_http_upstream_module

Defines server groups that can be referenced by fastcgi_pass , proxy_pass , uwsgi_pass , etc.

C10K Problem

Inability to handle 10 000 simultaneous network sockets.

Compressing Requests to Upstream

Use the gunzip filter to decompress gzip‑encoded responses for clients that do not support it.

Getting Current Time

Use SSI with $date_gmt or $date_local variables, e.g., proxy_set_header THE-TIME $date_gmt;

Purpose of -s Flag

Controls Nginx runtime actions (e.g., reload, stop) via the nginx -s command.

Adding Modules to Nginx

Modules must be compiled into Nginx at build time; they cannot be loaded dynamically.

Setting Worker Process Count

Match the number of CPU cores; one worker per core yields optimal performance.

Nginx Status Codes

499 – client closed connection.

502 – bad gateway (possible FastCGI, buffer, or timeout issues).

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 32k;
fastcgi_buffers 8 32k;
proxy_buffer_size 16k;
proxy_buffers 4 16k;

For more details, refer to the original source.