Reverse Proxy

How it works

A reverse proxy sits in front of one or more origin servers and receives requests on their behalf. Clients connect to it believing it is the application, and it decides what reaches the real servers behind it. It is the mirror image of a forward proxy: the same brokering machinery, deployed by the side receiving traffic rather than the side sending it, so the policy belongs to the service owner.

Because it is the single point every request passes through, it becomes the natural home for work the origin should not repeat. Typically that means terminating TLS, routing by hostname or path, distributing requests across backends, caching responses, compressing output, applying rate limits, adding security headers, and increasingly enforcing authentication before a request ever reaches application code.

When it matters

It matters as soon as you have more than one of anything: more than one backend instance, more than one service behind one domain, or more than one place a rule needs to be applied consistently. It also matters when you want to change what is behind a URL without changing DNS, which is what makes blue-green deploys and gradual migrations practical.

The security value is concentration. A rate limit, a header policy, or a WAF rule applied at the reverse proxy applies to every request, including requests to the endpoint someone forgot about. The same concentration is the risk: a misconfiguration there is also universal, and a mismatch between how the proxy and the backend parse a request is the root cause of HTTP request smuggling.

Common misconceptions

• "A reverse proxy is just a load balancer." Load balancing is one job a reverse proxy can do. Termination, routing, caching, and authentication are others, and plenty of reverse proxies sit in front of exactly one backend and never balance anything.
• "Putting a reverse proxy in front makes the application secure." It shifts where the boundary is. If the origin is still reachable directly, the boundary is decorative. Origins must be network-restricted to the proxy for the control to mean anything.
• "More proxy hops means more protection." Each additional hop is another parser that can disagree with its neighbour about where a request ends, which is precisely the condition request smuggling exploits. Keep the chain deliberate and short.