If you've ever set up a website behind Cloudflare, run more than one app on a single server, or added HTTPS to a site through a tool that "just handled it," you've used a reverse proxy without necessarily thinking of it as one. It's unglamorous, invisible when it's working, and quietly holds together a huge amount of the web's actual architecture.
What a reverse proxy actually does
Strip away the jargon and the job is simple: a reverse proxy sits in front of one or more backend servers, receives incoming requests, and forwards them on to wherever they actually need to go. The client — a browser, an app, another server — only ever talks to the proxy. It never connects to the real backend directly, and often has no way to know the backend exists at all.
The proxy takes the response from the backend and passes it back to the client as if it had generated it itself. From the outside, the proxy is the server. What's actually happening behind it — one machine, several machines, a mix of old and new infrastructure, a service that got moved somewhere else last week — is invisible to anyone on the other end of the connection.
The short version: a reverse proxy is an intermediary that stands in front of your real servers, so clients talk to it instead of talking to them directly. Everything else — TLS termination, caching, load balancing, routing by domain name — is something a reverse proxy can do on top of that basic job, not what defines it.
Forward proxy vs reverse proxy
The word "proxy" alone is ambiguous, and it's worth being precise about which direction it's facing, because the two are almost mirror images of each other:
| Forward proxy | Reverse proxy | |
|---|---|---|
| Sits in front of | Clients | Servers |
| Who knows it's there | The client, deliberately | Usually nobody on the client side |
| What it hides | Which specific client made the request | Which specific server handled the request |
| Typical use | Content filtering, client anonymisation, bypassing network restrictions | TLS termination, routing, caching, load balancing |
A forward proxy works on behalf of clients, reaching out to the internet for them — the server on the other end doesn't know or particularly care which specific client actually originated the request, just that it came through the proxy. A reverse proxy works on behalf of servers, receiving requests for them — the client doesn't know or care which specific backend actually handled it. Same underlying mechanism, opposite side of the conversation.
Why it's not the same thing as a load balancer
This is the mix-up worth clearing up properly, because the confusion is understandable: a lot of software (Nginx, HAProxy, Caddy, and others) can do both jobs, and it's common to see the terms used loosely, even interchangeably, in casual conversation. But they're answering different questions.
- A reverse proxy's core job is being an intermediary in front of backend servers. It works perfectly well in front of exactly one server, with nothing to balance at all — TLS termination, routing by domain name, and adding security headers in one place are all things a single-backend reverse proxy does every day.
- A load balancer's core job is distributing traffic across multiple backend servers, using some strategy (round-robin, least-connections, health-check-aware routing) to decide which one handles a given request. Without more than one backend, there's genuinely nothing for a load balancer to do.
Load balancing is a feature a reverse proxy is commonly configured to provide once you have more than one backend to distribute across. It's not the definition of what a reverse proxy is. Plenty of reverse proxies run their entire useful life in front of a single server and never touch a load-balancing decision, and that's a completely normal, valid deployment — not a proxy running "under capacity."
The mix-up that causes real confusion: assuming you need "a load balancer" when what you actually need is a reverse proxy, or the reverse. If you have one backend and want TLS termination, clean routing, and a single point for security headers, a reverse proxy solves that on its own. Load balancing only becomes relevant once there's more than one backend actually competing for requests.
Common use cases
A reverse proxy earns its place in an architecture well before there's enough scale to need multiple backend servers. The common reasons it shows up:
- TLS termination. The proxy handles the HTTPS encryption and decryption, talking to the backend over plain HTTP internally. This centralises certificate management in one place instead of configuring TLS separately on every backend service.
- Running multiple applications on one IP address. The proxy inspects the requested domain name and routes to the correct backend accordingly — several sites or services sharing one public-facing entry point, each unaware of the others.
- Caching. Frequently requested content can be served straight from the proxy without hitting the backend at all, reducing load on servers that would otherwise regenerate the same response repeatedly.
- A single point for security controls. Rate limiting, security headers, IP blocking, and request filtering can all be applied once, at the proxy, rather than replicated across every backend service individually.
- Hiding backend topology. Clients never learn how many servers exist, what they're running, or where they physically sit. That's a meaningfully smaller attack surface than exposing backend servers directly to the internet.
- Compression and protocol handling. Gzip/Brotli compression, HTTP/2 or HTTP/3 support, and WebSocket proxying can all be handled centrally rather than requiring every backend application to implement them itself.
The practical upshot: almost any web-facing setup benefits from a reverse proxy sitting in front of it, independent of scale. It's not an "enterprise" pattern reserved for businesses running clusters of servers — a single small VPS running one application behind a reverse proxy for TLS termination and clean routing is an entirely normal, sensible default.
If you want the personal, warts-and-all version of how a reverse proxy ends up becoming someone's daily-driver web server rather than just the thing sitting in front of it, we've written about that experience separately — the Nginx vs Apache piece is the story of exactly that shift, told from the reverse-proxy door in rather than as an architecture explainer.
Working out whether your setup needs a reverse proxy, or already has one doing more than it should? Get in touch and we'll talk through what's actually happening in front of your servers.
Get in touch →Frequently asked questions
What does a reverse proxy actually do?
It sits in front of one or more backend servers and handles incoming requests on their behalf. The client only talks to the proxy, never the backend directly, and the proxy forwards the response back as if it generated it itself.
Is a reverse proxy the same thing as a load balancer?
No, though the same software often does both. A reverse proxy's core job is being an intermediary — it works fine in front of a single server. A load balancer's core job is distributing traffic across multiple backends. Load balancing is a feature a reverse proxy can provide, not its definition.
What is the difference between a forward proxy and a reverse proxy?
A forward proxy sits in front of clients and requests on their behalf. A reverse proxy sits in front of servers and receives requests on their behalf. Same mechanism, opposite side of the conversation.
Why would a small website need a reverse proxy?
Even a single-server site benefits from TLS termination, running multiple apps on one IP by domain name, centralised security headers and rate limiting, and caching — all useful well before there's enough traffic to need load balancing.