Understanding Nginx: Core Concepts, Configuration, and Advanced Features

Nginx is a lightweight, high‑performance web server and reverse proxy that consumes minimal memory, starts quickly, and excels at handling tens of thousands of concurrent connections, making it popular among large‑scale internet projects such as Sina, NetEase, and Tencent.

Key Advantages include cross‑platform support, simple configuration, non‑blocking I/O, low memory footprint (10 instances use ~150 MB), open‑source licensing, high stability, and built‑in health‑check capabilities that automatically bypass failed upstream servers.

Typical Use Cases are serving static HTTP content, virtual hosting multiple sites on one machine, reverse proxying and load balancing for backend services, and acting as an API gateway with security controls.

Request Processing Flow : on startup Nginx parses its configuration, creates listening sockets in the master process, forks worker processes, and each worker competes for incoming connections. Once a connection is accepted, Nginx creates a ngx_connection_t structure, assigns read/write event handlers, and exchanges data with the client. Connections are closed by either side when communication ends.

High Concurrency Model : unlike a one‑process‑per‑request model, Nginx uses an asynchronous, non‑blocking event loop (epoll) so a small number of worker processes can handle massive concurrent traffic by sleeping while waiting for I/O events.

Proxy Types : a forward proxy sits between a client and the origin server, while a reverse proxy sits in front of backend servers, hiding their details and providing security, load balancing, and caching.

Directory Structure (excerpt):

tree /usr/local/nginx
├── client_body_temp
├── conf
│   ├── fastcgi.conf
│   ├── mime.types
│   └── nginx.conf
├── html
│   ├── 50x.html
│   └── index.html
├── logs
│   ├── access.log
│   └── error.log
├── sbin
│   └── nginx
└── ...

nginx.conf Modules example:

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 : cookies are stored client‑side, can be read/modified by the browser, and are sent via HTTP headers, while sessions reside on the server (files, DB, Redis), store sensitive data, and are referenced by a cookie containing a session identifier.

Why Nginx Uses No Threads : Apache creates a process or thread per request, consuming CPU and memory, whereas Nginx uses a single‑threaded event loop per worker, avoiding per‑request resource allocation and reducing context switches.

Static/Dynamic Separation : static assets (HTML, CSS, JS, images) are served directly by Nginx, while dynamic requests are proxied to application servers such as Tomcat, improving response speed and reducing backend load. CDN services can further cache static resources.

Load‑Balancing Algorithms supported:

Round‑robin (default)

Weight‑based

IP‑hash

Fair (third‑party module)

URL‑hash (third‑party module)

Example configuration for round‑robin:

upstream backserver {
    server 192.168.0.12;
    server 192.168.0.13;
}

Cross‑Origin Handling : configure Nginx to proxy API calls from the same origin, effectively bypassing browser CORS restrictions.

Virtual Host Configuration can be based on domain name, port, or IP address. Example for domain‑based hosts:

# www.lijie.com
server {
    listen 80;
    server_name www.lijie.com;
    location / { root data/www; index index.html index.htm; }
}

# bbs.lijie.com
server {
    listen 80;
    server_name bbs.lijie.com;
    location / { root data/bbs; index index.html index.htm; }
}

location Directive matches request URIs with varying priority (exact, prefix, regex, case‑insensitive regex) and can return specific status codes or map to file system paths.

Rate Limiting (Traffic Shaping) uses the leaky‑bucket algorithm via ngx_http_limit_req_module and ngx_http_limit_conn_module. Example for basic request rate limiting:

# Define a zone limiting one 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://lj_seckill;
    }
}

Burst handling with burst and nodelay allows short spikes to be processed immediately.

Health Checks can be performed with built‑in ngx_http_proxy_module and ngx_http_upstream_module or with the third‑party nginx_upstream_check_module for more advanced monitoring.

Compression is enabled with the gzip module:

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 proxy_pass, fastcgi_pass, uwsgi_pass, etc.

C10K Problem refers to the difficulty of handling 10,000 simultaneous connections, which Nginx solves through its event‑driven architecture.

Worker Process Tuning : set worker_processes to match the number of CPU cores for optimal performance; on a single‑core system, a single worker is sufficient.

Nginx Status Codes such as 499 (client closed request) and 502 (bad gateway) often indicate upstream or timeout issues, which can be mitigated by adjusting proxy_*_timeout, fastcgi_*_timeout, and buffer sizes.