NGINX Fundamentals

NGINX is a web server, reverse proxy, and load balancer. It accepts HTTP (and other protocol) connections, decides what to do with each request based on its configuration, and either serves a file directly or hands the request to another process. It runs some of the busiest sites on the internet because of how it handles concurrency: one small set of worker processes serves thousands of simultaneous connections without spawning a thread or process per connection.

The useful mental model is a request router with a rulebook. The rulebook is the configuration file. Every incoming request gets matched against that rulebook — first to a virtual server, then to a location inside it — and the matched rule decides what happens next: serve a file, proxy to a backend, redirect, or reject.

Why NGINX exists

Early web servers like Apache HTTP Server handled each connection with a dedicated process or thread. That model is simple to reason about, but it does not scale gracefully when a server needs to hold open thousands of slow or idle connections — the C10K problem. NGINX was built around an event-driven, asynchronous architecture instead: a fixed number of worker processes each run an event loop and multiplex many connections without blocking on any single one.

That architecture makes NGINX a natural fit for jobs that involve high connection counts or connection reuse, not just raw CPU-bound page rendering:

• serving static files (HTML, images, CSS, JavaScript) at high concurrency;
• terminating TLS in front of application servers;
• reverse-proxying requests to application backends (PHP-FPM, Node.js, Python WSGI/ASGI apps, Java application servers);
• load balancing across multiple backend instances;
• acting as an API gateway or edge cache.

Master and worker processes

An NGINX instance is a master process plus one or more worker processes.

• The master process reads and validates the configuration file, opens listening sockets, and manages workers — starting, stopping, and restarting them as needed. It does not handle client requests itself.
• Worker processes do the actual work: accepting connections, reading requests, running the configured logic, and talking to upstream servers. Each worker runs an event loop and can hold many connections open at once.