# What NGINX Does and How It Works — Nginx

Source: https://www.skillbyai.com/en/nginx/f-what

> Explain NGINX's roles and its event-driven architecture.

## Web server, reverse proxy, load balancer

**NGINX** (pronounced "engine-x") is a high-performance **web server**, **reverse proxy**, **load balancer** and **HTTP cache**, created by Igor Sysoev and first released in 2004 to solve the "C10K" problem of handling ten thousand concurrent connections. Today it fronts a large share of the world's websites. Its speed comes from its architecture: a **master process** reads configuration and manages a small number of **worker processes** (typically one per CPU core), and each worker handles **thousands of connections** in a single-threaded, **event-driven, non-blocking** loop using the operating system's efficient event APIs (epoll on Linux, kqueue on BSD and macOS). Instead of dedicating a thread to each connection, a worker reacts to events ("data arrived", "socket writable") and moves on, so memory use stays low under heavy concurrency. **NGINX Open Source** is free; **NGINX Plus** (from F5) adds commercial features such as active health checks and an API for dynamic configuration. Forks such as **Angie** and **freenginx** also exist.

## Master and workers

One master manages several workers; each worker multiplexes many connections with an event loop.

![A small top box connected to four worker boxes, each worker surrounded by many tiny dots representing connections, with a circular arrow inside each worker.](assets/figures/nginx/section-1-map.svg) — Figure 1.1 — The master process and event-driven worker processes.

## NGINX in front of an application

A typical request path through NGINX.

```text
browser --HTTPS--> NGINX (TLS, compression, static files, caching, rate limits)
                     |-- /assets/*  -> served from disk
                     |-- /api/*     -> proxied to app servers (load balanced)
                     '-- /ws        -> WebSocket upgrade proxied to realtime service

ps -ef | grep nginx
# expect one "master process" line and one "worker process" line per core
# when worker_processes is set to auto
```

## NGINX is not your application server

NGINX excels at connections, TLS, static files and proxying. Your business logic runs in an application server (Node.js, Gunicorn, PHP-FPM, a Java service) behind it.

**Quiz:** How does an NGINX worker process handle many connections at once?

- [x] With a single-threaded, event-driven, non-blocking loop
- [ ] By creating a new thread per connection
- [ ] By forking a process per request
- [ ] By queuing connections until one finishes

*Answer:* With a single-threaded, event-driven, non-blocking loop. Workers react to I/O events for thousands of connections without a thread per connection.