What nginx is

Scope: the two jobs nginx does, the shape of the program that does them, and where it sits relative to the other server in this series.

Job one: web server

A web server answers HTTP requests with files. A browser asks for /hello.txt; nginx finds the file on disk and sends it back, with a status line saying how it went:

$ curl -s http://127.0.0.1:8080/hello.txt
main root: plain file hello.txt

That is the whole of job one, and for static sites — HTML, images, downloads — it is all you need.

Job two: reverse proxy

Most interesting things on the web aren't files; they're programs that produce responses when asked. Those programs usually speak HTTP on some port of their own — say 9001 — and are not built to face the internet: no TLS, no patience for slow clients, logs that assume a trusted caller.

A reverse proxy stands in front:

visitor ──► nginx :8080 ──► your app :9001
              │                    │
              ◄──── response ──────┘

The visitor talks to nginx. nginx opens a second, separate connection to the app, asks on the visitor's behalf, and relays the reply. From the lab, measured against an echo backend that prints what it received: the app sees the request arrive from nginx, and only learns who the real visitor was if nginx tells it (chapter 7 is about that telling).

Why bother? One public door for many apps, TLS in one place, static files served without waking the app, and a buffer between the internet's manners and your program's.

The shape of the program

nginx is one master process and a small number of worker processes:

$ ps aux | grep "nginx:"
root  13739  ... nginx: master process nginx -p .../prefix -c .../nginx.conf
root  13779  ... nginx: worker process
root  13780  ... nginx: worker process

The master reads the config, binds the ports, and supervises. The workers do the actual serving — each one handling many connections at once, which is why two workers can front a very busy site. Two consequences worth keeping:

Reloading is cheap and safe. The master can start fresh workers on a new config while old workers finish their current requests (chapter 4).
On a normal install the workers are not root. The Ubuntu package runs them as the www-data user, so a worker can only read files www-data can read. (This lab's workers run as root — a sandbox quirk explained in chapter 2, not a habit to copy.)

nginx and Caddy

This series also has a Caddy for Mere Mortals guide, and the two tools overlap almost completely in what they do. The difference is posture. Caddy automates: certificates appear and renew themselves, and the config for a proxied site is three lines. nginx is explicit: every behaviour is a directive you wrote, the config is longer, and certificates are a separate job (chapter 9 shows the manual version). nginx's compensation is ubiquity — it has been the standard for long enough that hosting panels, tutorials, and the machine you just inherited all assume it.

Check: you should be able to say which of the two jobs a given nginx is doing — and that "the site is down" might mean nginx is up and the app behind it isn't. Chapter 7's 502 makes that distinction concrete.