Reverse Proxies: Nginx, Caddy and What Sits in Front

What it takes off your hands

• TLS termination — certificates in one place, renewed automatically.
• Static file serving — far faster than any application runtime.
• Request buffering — a slow client occupies a cheap proxy connection instead of an expensive application worker.
• Compression — gzip or Brotli applied once, centrally.
• Routing — several applications or services behind one hostname and port.
• Rate limiting — abusive traffic stopped before it reaches your code.
• Caching — repeated responses served without touching the application.
• Header handling — security headers set consistently everywhere.

Request buffering is the underrated one. Without it, a client on a slow mobile connection ties up an application worker for the whole upload.

Nginx or Caddy

Caddy gets a site to working HTTPS in about five lines and handles renewal without a cron job. Nginx has an answer to every unusual requirement and a decade of documented solutions. Neither is a bad choice; pick for familiarity.

Traefik is a third option worth knowing if you run containers, since it configures routes from container labels automatically.

The details that go wrong

1. Forward the client address. Set X-Forwarded-For and X-Forwarded-Proto, and configure the application to trust the proxy. Otherwise every request appears to come from 127.0.0.1.
2. Set body size limits. Nginx defaults to 1 MB, which breaks file uploads with a confusing 413.
3. Set timeouts deliberately. Proxy read timeouts shorter than your slowest endpoint produce 504s that look like application errors.
4. Enable HTTP/2, which is one directive and a real latency improvement.
5. Serve static files directly rather than proxying them to the application.
6. Add security headers once, at the proxy: HSTS, X-Content-Type-Options, Referrer-Policy, and a content security policy if you can maintain one.

Bind the application to localhost

With a proxy in front, the application should listen on 127.0.0.1 or a Unix socket, never on 0.0.0.0. This means a firewall mistake cannot expose it directly, and all traffic necessarily passes through the proxy’s rules.

It is one configuration line and it removes an entire class of accidental exposure.

Caching at the proxy

Nginx can cache upstream responses, which turns repeated dynamic requests into static ones. Even a ten-second cache on a busy page removes most of the load.

• Cache only responses that are safe to share between users. Never cache a page containing session-specific content.
• Vary on the headers that genuinely change the response, and no more.
• Ignore query parameters you do not use, so cache busting fails.
• Set stale-while-revalidate behaviour so users get a fast response while the cache refreshes.

Proxy or managed load balancer

They overlap. A managed load balancer gives redundancy and managed certificates without maintenance; a self-hosted proxy gives caching, rewriting and routing logic that managed products often lack.

A common arrangement uses both: a managed load balancer for TLS and distribution, and a proxy on each server for caching, static files and application-specific routing.

Common questions

Where to go next

See load balancing basics and CDN and caching.