Reverse Proxies: TLS, Caching and Hiding the Origin

A reverse proxy is a server that stands in front of one origin, receives every client request in its place, and forwards it on. Along the way it does work the origin would otherwise do: it handles the encryption, caches responses, compresses them, and keeps the origin's address out of sight.

Why "reverse". A forward proxy works for clients: an office network's proxy sends employees' requests out to the internet. A reverse proxy works for a server: it receives requests from the internet on that server's behalf. The client believes the proxy is the site.

What it takes on. TLS termination means the proxy decrypts https traffic, so the origin receives plain HTTP on a private network and holds no certificate. Caching means repeated requests for the same page are answered by the proxy without reaching the origin. Compression shrinks responses before they cross the internet. Hiding the origin means attackers see only the proxy's address, and the origin can refuse anything that does not come from it.

Where you meet it. NGINX in front of a Node.js or Python application is the common case: the application listens only on the private network and NGINX faces the internet. Cloudflare plays the same part at a global scale, with its edge servers as the proxy.

What it is not. A reverse proxy in front of one server spreads no load, because there is only one place to send requests. Put several origins behind it and choose among them, and it has become a load balancer as well.

So put a reverse proxy in front of an origin when it should do none of the work of facing the internet: encryption, caching and exposure all move to the proxy.