Why Nginx?
Somewhere between your users and your application code sits a piece of software whose whole job is handling raw HTTP traffic well: accepting thousands of connections, serving files fast, terminating TLS, and passing the interesting requests to your app. On roughly a third of all websites — including this one — that software is Nginx (pronounced "engine-x").
💡 The Bottom Line
Nginx is three tools in one binary, all configured the same way: a web server (serving files over HTTP), a reverse proxy (forwarding requests to backend apps), and a load balancer (spreading traffic across several backends). Learn its config language once and you can do all three.
The problem it was built to solve
Nginx was written to answer the "C10K problem" — how does one server handle ten thousand simultaneous connections? The dominant server of the time (Apache) used a worker per connection; ten thousand connections meant ten thousand threads' worth of memory, most of them idle, waiting on slow clients. Nginx instead uses a few event-driven worker processes, each juggling thousands of connections asynchronously — a connection waiting on a slow client costs almost nothing. That architecture is why a $5 VPS running Nginx can shrug off traffic that would flatten a naive server.
The three hats
- Web server — map URLs to files on disk and serve them, with caching headers, compression, and custom error pages. Perfect for static sites (Lesson 3).
- Reverse proxy — sit in front of your Node/Python/Go app: Nginx handles the raw internet (slow clients, TLS, buffering) and forwards clean requests to your app on localhost (Lesson 4).
- Load balancer — the same proxying, but across several backend servers, with health-aware distribution (also Lesson 4).
In practice most deployments combine hats: static assets served directly from disk,
/api proxied to an app, all behind TLS (Lesson 5).
🙋 There Are No Dumb Questions
Q: What makes a proxy "reverse"?
A: Direction. A forward proxy sits in front of clients — your office
routes employees' outbound browsing through it. A reverse proxy sits in front of
servers — users think they're talking to your site, but they're talking to Nginx,
which forwards to backends they never see. Same word, opposite ends of the connection.
⚠️ Watch Out
Nginx doesn't run your application code — there's no "deploy my Python app into Nginx." Your app runs as its own process (or container) listening on its own port, and Nginx forwards HTTP to it. Coming from Apache's mod_php world this separation surprises people, but it's a feature: your app server and your traffic handler scale, restart, and fail independently.
🔧 Try It Yourself
The fastest way to a running Nginx is Docker (no system install needed):
docker run -d --name nginx-lab -p 8080:80 nginx:1.27Visit http://localhost:8080 — that's the default welcome page. On a Linux
server you'd instead run sudo apt install nginx and get the same thing on
port 80. Keep this container around: the whole track's exercises work inside it.
✅ Quick Check
Why can Nginx handle thousands of simultaneous connections so cheaply?
Next up: the config language everything else in this track is written in — directives,
blocks, and the nginx -t habit that will save your site someday.