Glossary
Reverse Proxy
Meaning and details
A reverse proxy is the doorman in front of your app: clients talk to it, it talks to your servers, and along the way it terminates TLS, compresses responses, caches static content, routes by path, load balances across in...
Reverse Proxy meaning
A server that sits in front of your application, receiving client requests and forwarding them, adding TLS, caching and routing.
What is Reverse Proxy?
A reverse proxy is the doorman in front of your app: clients talk to it, it talks to your servers, and along the way it terminates TLS, compresses responses, caches static content, routes by path, load balances across instances and shields the origin from direct exposure. Nginx and Caddy are the self-hosted classics, Traefik the container-native favorite, and Cloudflare a proxy as a service, the same idea at planetary scale.
Why it matters to an indie builder: the reverse proxy is the quiet Swiss army knife of small deployments. One machine can host five services under one domain, each routed by path or subdomain, because the proxy multiplexes. Zero-downtime deploys become possible, the proxy drains old instances while new ones take traffic. And it is the enforcement point for the boring security basics: rate limits, request size caps, and hiding the app server from the open internet, which is the difference between a CVE being reachable and being theoretical.
A concrete example: a $6 VPS runs a Laravel app on port 8080 and a docs site on 3000. Caddy in front holds the TLS certificates, auto-renewed, routes app.example.com to 8080 and docs.example.com to 3000, compresses responses and serves the static assets itself. Total configuration: eleven lines, one file. The certificates alone, obtained, renewed and reloaded without cron jobs or manual ceremony, repay the setup every ninety days forever, and the underlying apps never handle TLS at all.
Common mistakes: exposing app ports directly and letting the proxy rot unused, which forfeits every protection above, proxying without caching and re-serving identical responses per request, forwarding the original client IP incorrectly, so rate limits and logs blame the proxy, pass the X-Forwarded-For header properly, and treating the proxy as a firewall substitute, it filters and shields, but the app still must validate inputs and authenticate requests as if it were naked.