Skip to content

Chapter 1 of 8

Nginx Fundamentals and Process Model

Nginx — pronounced "engine x" — is a high-performance open-source HTTP server, reverse proxy, and IMAP/POP3 mail proxy originally written by Igor Sysoev and first released in 2004. It is built around a single master process that reads and validates the configuration, manages listening sockets, and spawns a configurable number of worker processes. By default the master creates one worker per CPU core, and every worker handles incoming connections using an event-driven, non-blocking loop. This architecture is what makes nginx able to serve tens of thousands of concurrent connections with very little memory compared to traditional process-per-request servers like Apache.

Because workers are long-lived, you can change the configuration or even upgrade the binary without dropping user connections. To do so, send SIGHUP to the master process (or run nginx -s reload): the master re-reads the configuration, starts new workers running the new settings, and gracefully drains the old workers once their existing requests finish. Two other shutdown signals are worth distinguishing. nginx -s stop sends SIGTERM and forces workers to exit immediately, closing any open connections. nginx -s quit sends SIGQUIT, which lets workers finish serving their current requests before exiting cleanly. Choosing between them is mostly about whether you can tolerate dropped sessions.

Before applying any change in production you can validate the syntax safely with nginx -t. This command parses the configuration files, includes, and referenced certificates without starting or reloading the server. The companion flag nginx -T goes one step further and dumps the fully expanded configuration to stdout, which is invaluable in CI/CD pipelines and when debugging complex include chains. On Linux the main configuration file lives at /etc/nginx/nginx.conf, with additional files typically loaded via include /etc/nginx/conf.d/*.conf; and per-site configs under /etc/nginx/sites-enabled/. Treat the configuration as a small, declarative program: write it, test it, then reload it.

All chapters
  1. 1Nginx Fundamentals and Process Model
  2. 2Core Configuration Directives and Performance Knobs
  3. 3HTTP Routing: Servers, Locations, and Rewrites
  4. 4Reverse Proxying, Upstreams, and Backend Protocols
  5. 5Caching and Compression
  6. 6TLS, SSL, and Connection Hardening
  7. 7Access Control, Rate Limiting, and Logging
  8. 8Advanced Routing, Variables, and Security Headers

Drill it

Reading is not remembering. These come from the Nginx Configuration Essentials deck:

Q

What does nginx stand for?

engine x — a high-performance open-source HTTP server, reverse proxy, and IMAP/POP3 mail proxy originally written by Igor Sysoev and first released in 2004...

Q

What is nginx's primary process model?

A single master process that reads configuration, manages sockets, and spawns worker processes (default count = CPU cores). Workers handle all incoming connecti...

Q

How do you reload nginx configuration without dropping connections?

Send SIGHUP to the master process (or run nginx -s reload). The master re-reads config, spawns new workers with the new config, and gracefully shuts down old wo...

Q

What is the difference between <code>nginx -s stop</code> and <code>nginx -s quit</code>?

stop sends SIGTERM to workers and forces them to exit immediately, closing open connections. quit sends SIGQUIT, which lets workers finish serving current reque...