Understanding Nginx: HTTP Server, Reverse Proxy, and Modular Gateway Architecture

Starting from a plain txt file opened in a browser, the article shows how adding HTML tags (e.g., <h1> , <ul> , <img> ) turns it into a rich web page, illustrating the role of tags in rendering.

When such an HTML file is served from a remote server, a process that provides an HTTP service is needed; this is the basic concept of an HTTP server, which delivers the HTML to browsers upon request.

The article then introduces the need for a reverse proxy to hide backend services behind a single URL, enabling load balancing, logging, compression, rate limiting, and other gateway functions.

To make the gateway extensible, Nginx supports modular capabilities configured in nginx.conf , allowing users to enable logging, compression, rate limiting, IP blocking, and custom modules.

Although Nginx originally processes all connections in a single thread, it avoids concurrency overhead by handling each request sequentially within that thread.

To scale, Nginx spawns multiple worker processes that listen on the same IP and port; the OS distributes incoming connections among them, and the number of workers is typically set to match the CPU core count.

Because workers are independent, shared memory is introduced so they can coordinate stateful features such as rate limiting.

For caching, Nginx can store proxy responses either in shared memory or on disk (proxy cache), trading storage space for reduced latency and network load.

A master process reads nginx.conf and manages the lifecycle of workers, enabling graceful rolling upgrades without dropping connections.

Finally, the article notes that a single Nginx instance is a single point of failure and hints at clustering solutions for high availability.