Understanding Nginx: Architecture, Modules, and High‑Performance Processing

What is Nginx?

Nginx (Engine X) is a high‑performance HTTP and reverse‑proxy web server written in C, also offering IMAP/POP3/SMTP services. It runs on many operating systems (Linux, FreeBSD, Solaris, macOS, AIX, Windows) and is distributed under a BSD‑like license. First released in 2004, it is widely used by major Chinese sites such as Baidu, JD, Sina, NetEase, Tencent, and Taobao.

Reverse Proxy and Forward Proxy

Reverse Proxy receives client requests from the Internet, forwards them to internal servers, and returns the responses as if it were the origin server. Clients see only the proxy, not the backend servers.

Forward Proxy is used when clients cannot directly access external resources (e.g., due to firewalls). The client sends a request to the proxy, which fetches the target content and returns it, hiding the client’s identity from the destination.

Nginx Architecture

Module Classification

Nginx modules are divided by structure and function:

Core modules: HTTP, EVENT, MAIL

Basic modules: HTTP Access, HTTP FastCGI, HTTP Proxy, HTTP Rewrite

Third‑party modules: HTTP Upstream Request Hash, Notice, HTTP Access Key

Functionally they fall into four categories:

Core : builds the basic service and manages other modules.

Handlers : process requests and generate output.

Filters : modify the output of handlers (e.g., compression, SSI).

Proxies : interact with upstream services such as FastCGI, implementing load balancing.

Module Processing Flow

When a request arrives, Nginx maps it to a location block in the configuration. The block’s directives trigger the appropriate handler, which may invoke a proxy, filter, or other module to fulfill the request.

Handlers return OK, ERROR, or delegate to the default handler.

If a handler proxies to an upstream server, a load‑balancing module (round‑robin or IP‑hash) selects the backend.

Filters are chained; each filter processes the response and passes it to the next, similar to a Unix pipeline.

Request Processing Phases

Nginx processes a request through a series of phases, each with its own handlers:

NGX_HTTP_POST_READ_PHASE – read request body

NGX_HTTP_SERVER_REWRITE_PHASE – rewrite server‑level URLs

NGX_HTTP_FIND_CONFIG_PHASE – locate configuration

NGX_HTTP_REWRITE_PHASE – rewrite location‑level URLs

NGX_HTTP_ACCESS_PHASE – access control checks

NGX_HTTP_TRY_FILES_PHASE – try_files handling

NGX_HTTP_CONTENT_PHASE – generate content (handler or static file)

NGX_HTTP_LOG_PHASE – logging

During the content phase, if no explicit content handler is configured, Nginx falls back to serving static files, index files, auto‑index listings, gzip‑static files, etc.

Master‑Worker Multi‑Process Model

The master process reads and validates nginx.conf, then forks multiple worker processes (typically one per CPU core). Workers run a single thread that handles connections using an event‑driven loop (epoll/kqueue). The master also manages worker lifecycles.

Workers compete for incoming connections. Nginx uses an accept_mutex to ensure only one worker registers the accept event at a time, preventing the “thundering herd” problem. The ngx_accept_disabled value can be tuned to control how aggressively workers give up the accept lock, balancing load across workers.

Hot Reload and High Availability

Nginx supports hot reload: after editing nginx.conf, the master process can reload the configuration without stopping service ( nginx -s reload), preserving existing connections.

For high availability, Nginx is often paired with Keepalived. Keepalived provides a virtual IP (VIP) and monitors Nginx health; if Nginx fails, Keepalived promotes a standby instance, ensuring continuous service.

In summary, Nginx’s lightweight, event‑driven, multi‑process architecture, modular design, and flexible configuration make it a powerful solution for high‑concurrency web serving, reverse proxying, load balancing, and fault‑tolerant deployments.