Master Nginx: Core Concepts, Configuration, and Performance Tuning

What Is Nginx?

Nginx is a lightweight, high‑performance reverse‑proxy web server that supports HTTP, HTTPS, SMTP, POP3, and IMAP. It efficiently handles 20‑30 k concurrent connections (officially up to 50 k) and is widely used by large Chinese sites such as Sina, NetEase, and Tencent.

Key Advantages of Nginx

Cross‑platform and simple configuration.

Non‑blocking, high‑concurrency handling of 20‑30 k connections (up to 50 k reported).

Low memory usage: ten Nginx processes consume about 150 MB.

Low cost and open source.

High stability with very low crash probability.

Built‑in health‑check: failed upstream servers are automatically bypassed.

Typical Application Scenarios

Standalone HTTP server for static content.

Virtual hosting to serve multiple sites on one machine.

Reverse proxy and load balancing for high‑traffic sites.

API gateway and security management.

How Nginx Processes Requests

server { # first server block – a virtual host
    listen 80; # default port
    server_name localhost;
    location / {
        root html; # document root
        index index.html index.htm;
    }
}

When Nginx starts, it parses the configuration, creates listening sockets, forks worker processes, and each worker competes for incoming connections. A worker that accepts a connection creates an ngx_connection_t structure, registers read/write event handlers, and exchanges data with the client. The connection is closed when either side terminates.

High‑Concurrency Mechanism

Nginx uses an asynchronous, non‑blocking event model (epoll) so a small number of worker processes can handle massive concurrent requests. Workers only block while waiting for upstream responses; otherwise they return to the event loop, allowing efficient use of CPU and memory.

Forward vs. Reverse Proxy

A forward proxy sits between a client and the origin server, fetching resources on behalf of the client. A reverse proxy receives external requests and forwards them to internal servers, hiding the origin servers from clients.

Benefits of Reverse Proxy

It hides the source servers, provides an additional security layer, and can perform load balancing, SSL termination, and caching.

Nginx Directory Structure

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

Key Directives in nginx.conf

worker_processes  1;               # number of workers
events {
    worker_connections 1024;    # max connections per worker
}
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. Cookies reside on the client browser, are visible and modifiable by the user, and are set via HTTP response headers. Sessions are stored on the server (files, database, Redis), keep sensitive data, and act as a server‑side lock.

Why Nginx Does Not Use Multithreading

Unlike Apache, which creates a process or thread per request, Nginx uses a single‑threaded, event‑driven model that avoids the overhead of many processes/threads and reduces context switches, enabling higher concurrency.

Nginx vs. Apache

Lightweight with lower memory and resource consumption.

Asynchronous, non‑blocking handling vs. Apache’s blocking model.

Modular design makes writing modules easier.

Apache uses a one‑connection‑one‑process model; Nginx uses many connections per process.

Static/Dynamic Resource Separation

Static resources (CSS, JS, images) are served directly by Nginx, while dynamic requests are proxied to an application server such as Tomcat. This reduces backend load and improves response time. CDN services (e.g., Qiniu, Alibaba Cloud) can further cache static assets for global acceleration.

How to Implement Static‑Dynamic Separation in Nginx

location /image/ {
    root /usr/local/static/;
    autoindex on;
}
# Create directory
mkdir -p /usr/local/static/image
# Upload files to the directory
# Reload configuration
sudo nginx -s reload

Access http://server_name/image/1.jpg to retrieve the static image.

Load‑Balancing Algorithms

Round‑robin (default): distributes requests sequentially.

Weight: assigns higher probability to servers with larger weight values.

IP‑hash: binds a client IP to a specific backend, useful for session persistence.

Fair (third‑party module): prefers servers with faster response times.

URL‑hash (third‑party module): hashes the request URL to achieve consistent routing.

# Round‑robin example
upstream backserver {
    server 192.168.0.12;
    server 192.168.0.13;
}
# Weight example
upstream backserver {
    server 192.168.0.12 weight=2;
    server 192.168.0.13 weight=8;
}
# IP‑hash example
upstream backserver {
    ip_hash;
    server 192.168.0.12:88;
    server 192.168.0.13:80;
}

Cross‑Origin Resource Sharing (CORS) with Nginx

Configure Nginx to proxy cross‑origin requests by forwarding them to the actual backend while exposing a same‑origin endpoint.

Virtual Host Configuration

Three common methods:

Domain‑based virtual hosts (e.g., www.example.com).

Port‑based virtual hosts (e.g., example.com:8080).

IP‑based virtual hosts.

# Domain‑based example
server {
    listen 80;
    server_name www.lijie.com;
    location / {
        root data/www;
        index index.html index.htm;
    }
}
# Port‑based example
server {
    listen 8080;
    server_name 8080.lijie.com;
    location / {
        root data/www;
        index index.html index.htm;
    }
}
# Proxy to backend on port 8080
server {
    listen 80;
    server_name www.lijie.com;
    location / {
        proxy_pass http://127.0.0.1:8080;
        index index.html index.htm;
    }
}

Location Directive

The location block matches request URIs and applies specific handling. Matching priority:

Exact match ( =)

Prefix match with ^~ Case‑sensitive regex ( ~)

Case‑insensitive regex ( ~*)

General prefix ( /)

# Exact match
location = / { return 400; }
# Prefix match (case‑sensitive)
location ^~ /av { root /data/av/; }
# Regex match (case‑sensitive)
location ~ /media { alias /data/static/; }
# Regex match (case‑insensitive, file extensions)
location ~* .*\\.(jpg|gif|png|js|css)$ { root /data/av/; }
# Fallback
location / { return 403; }

Rate Limiting (Traffic Shaping)

Nginx implements rate limiting using the leaky‑bucket algorithm via the ngx_http_limit_req_module and connection limiting via ngx_http_limit_conn_module.

Normal Request Rate Limiting

# Define a zone allowing 1 request per minute per IP
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;
server {
    location /seckill.html {
        limit_req zone=one;
        proxy_pass http://backend;
    }
}

Burst Limiting (Handling Spikes)

# Allow a burst of 5 requests with no delay
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;
server {
    location /seckill.html {
        limit_req zone=one burst=5 nodelay;
        proxy_pass http://backend;
    }
}

Concurrent Connection Limiting

http {
    limit_conn_zone $binary_remote_addr zone=myip:10m;
    limit_conn_zone $server_name zone=myServerName:10m;
}
server {
    location / {
        limit_conn myip 10;          # max 10 connections per IP
        limit_conn myServerName 100; # max 100 connections for the server
        rewrite ^ / permanent;
    }
}

Leaky Bucket vs. Token Bucket

The leaky‑bucket algorithm treats incoming requests as water poured into a bucket that drains at a fixed rate; excess water overflows and is dropped. The token‑bucket algorithm adds tokens to a bucket at a steady rate; a request proceeds only if a token is available.

High Availability Configuration

server {
    listen 80;
    server_name www.lijie.com;
    location / {
        proxy_pass http://backServer;   # upstream group
        proxy_connect_timeout 1s;
        proxy_send_timeout    1s;
        proxy_read_timeout    1s;
        index index.html index.htm;
    }
}

Blocking Specific IPs

# Return 403 for a particular IP
if ($remote_addr = 192.168.9.115) {
    return 403;
}

Restricting Browser Access

# Deny Chrome browsers with a 500 error
if ($http_user_agent ~ Chrome) {
    return 500;
}

Health Checks

Two approaches:

Use built‑in ngx_http_proxy_module and ngx_http_upstream_module health checks.

Install the third‑party nginx_upstream_check_module for more advanced checks.

Enabling Gzip Compression

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

After reloading Nginx, static assets such as jQuery shrink from ~90 KB to ~30 KB, reducing bandwidth usage.

ngx_http_upstream_module

This module defines groups of backend servers that can be referenced by proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_pass.

C10K Problem

The challenge of handling 10,000 simultaneous network connections, which Nginx addresses with its event‑driven architecture.

Compressing Requests to Upstream

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

Getting the Current Time

proxy_set_header THE-TIME $date_gmt;

Purpose of the -s Option

Controls Nginx runtime actions such as reload, stop, or quit.

Adding Modules

Modules must be selected at compile time; Nginx does not support dynamic module loading for all features.

Setting Worker Processes in Production

Match the number of workers to the number of CPU cores for optimal performance. On a single‑core system, a single worker is sufficient.

Common HTTP Status Codes and Troubleshooting

499 – client closed the connection before the server responded.

502 – possible FastCGI issues (process not started, insufficient workers, timeout, or buffer limits). Adjust fastcgi_connect_timeout, fastcgi_send_timeout, fastcgi_read_timeout, and buffer sizes as needed.