Capstone: Designing a Production Nginx Reverse-Proxy Tier

Web Servers Fundamentals' own capstone compared three servers across several scenarios. This one is different, by design: a single, cohesive worked example, layering in each of this course's own eight prior chapters, one at a time, until one complete production-shaped configuration exists.

The Scenario

A containerized API service runs three backend instances. It needs traffic distributed across them sensibly, protection from slow clients and abusive traffic, caching for its read-heavy public endpoints, correct client-identity forwarding, TLS termination, and basic real-time visibility — every one of this course's own chapters, applied to one real job.

Step 1 — Worker Tuning (Chapter 2)

worker_processes auto matches the container's own allotted CPU cores; worker_connections 2048 is set generously, on the assumption the OS file-descriptor limit has already been raised to match, per Chapter 2's own warning about the real ceiling being whichever of the two numbers is lower.

Step 2 — The Upstream Pool (Chapter 4)

Three backend instances form the pool, with keepalive 32 letting Nginx reuse its own connections to them (Chapter 4).

Step 3 — Choosing a Load Balancing Algorithm (Chapter 5)

least_conn, already shown above, is chosen deliberately: this API's own request times vary meaningfully by endpoint (Chapter 5's own case for preferring it over plain round robin), so routing toward whichever backend is currently least busy fits better than blindly cycling through the pool.

Step 4 — Reverse Proxy Headers (Chapter 6)

These live in the outer server {} block, so every location nested inside it inherits them automatically — a deliberate choice, since Chapter 6's own warning box showed that any nested block adding its own proxy_set_header would otherwise silently lose all of these.

Step 5 — TLS Termination

TLS itself is configured exactly per Web Servers Fundamentals Chapter 7 — listen 443 ssl, ssl_certificate/ssl_certificate_key — not repeated here since that chapter already covers it fully; this capstone assumes it's already in place ahead of everything else below.

Step 6 — Caching Read-Heavy Endpoints (Chapter 7)

Only the public, read-heavy /api/public/ path is cached — proxy_cache_bypass/proxy_no_cache on the session cookie keep any authenticated request out of the cache in both directions, exactly the discipline Chapter 7's own warning box insisted on.

Step 7 — Rate Limiting (Chapter 8)

A per-IP rate limit protects the backend pool from any single abusive client, with a burst allowance absorbing normal traffic spikes without rejecting legitimate short bursts.

Step 8 — Performance & Monitoring (Chapter 9)

proxy_buffering stays on deliberately (Chapter 9's own warning box), and stub_status is restricted to internal access only, giving ops visibility without exposing it publicly.

Hands-On Exercises