What Is a Reverse Proxy? The Front Desk That Sits in Front of Your Servers

Picture a busy office building. You don’t wander the hallways looking for the right person — you walk up to the front desk, say who you need, and the receptionist routes you to the correct room, takes a message, or politely turns you away. Visitors never see the messy floor plan behind that desk, and that’s the whole point. A reverse proxy is exactly this kind of front desk, but for your servers.

It’s one of those pieces of infrastructure that sits quietly in the middle of almost every real website, doing a dozen small jobs at once. Once you understand what it is and why it’s there, a lot of confusing things about how production sites are built — multiple servers, one domain, HTTPS everywhere, that sort of thing — suddenly start to make sense.

What a reverse proxy actually is

A reverse proxy is a server that sits between clients (browsers, apps, anything making requests) and one or more backend servers that actually do the work. Every incoming request hits the reverse proxy first. The proxy then decides what to do: forward it to a backend, answer it itself from a cache, reject it, or hand it off somewhere else entirely. When the backend replies, the response travels back through the proxy and out to the client.

From the outside, it looks like the client is talking to a single server. In reality, it’s talking to the proxy, and the proxy is quietly doing the real talking on its behalf. The client never needs to know how many servers are back there, what they’re called, or which one ended up handling the request.

That word “reverse” is doing a lot of work, and it confuses people, so let’s pin it down. A forward proxy sits in front of clients and represents them to the wider internet — think of a company proxy that all the employees’ browsers route through. A reverse proxy sits in front of servers and represents them to the clients. Same proxy idea, opposite side of the conversation.

How a request flows through it

Let’s walk a single request through, step by step, because the flow is the whole idea.

1. A client types acypartner.example into the browser and sends an HTTPS request. DNS points that domain at the reverse proxy’s public IP, so the request lands on the proxy — not on any backend directly.
2. The reverse proxy receives the request. It looks at things like the requested path, the host header, and maybe the user’s cookies, then decides where this should go.
3. It forwards the request to the right backend server over the internal network — say, the app server that handles /api, or the static-file server that handles images.
4. The backend does its work and sends a response back to the proxy.
5. The proxy passes that response back to the client, often adding or tidying a few things on the way (compression, headers, and so on).

   CLIENT                 REVERSE PROXY                BACKENDS
 (your browser)          (the front desk)         (the real workers)
      │                        │                        │
      │  1. GET /api/users     │                        │
      │ ─────────────────────► │   2. pick a backend    │
      │                        │ ─────────────────────► │  app server
      │                        │                        │  does the work
      │                        │ ◄───────────────────── │
      │  3. the response       │                        │
      │ ◄───────────────────── │                        │
      │                        │                        │
   sees ONE server                              there are MANY

Notice the asymmetry: the client sees one address and one server. Behind the proxy there might be five app servers, a separate machine for static files, and a cache — but none of that leaks out. The proxy is the single, stable public face of a system that can be as messy and changeable as it needs to be on the inside.

The jobs a reverse proxy quietly handles

A reverse proxy is rarely added for just one reason. It tends to accumulate responsibilities because it’s the perfect choke point — every request passes through it, so it’s the natural place to do anything that should apply to all traffic. Here are the jobs it most commonly takes on.

Routing requests to the right place

This is the core job. Based on the URL path, the domain, or the host header, the proxy sends each request to the backend that should handle it. Requests to /api/* go to the application server; requests for /images/* go to a static-file server; requests for blog.acypartner.example and shop.acypartner.example might go to entirely different systems — all behind one proxy, all looking like one site to the visitor.

TLS / HTTPS termination

Encrypting and decrypting HTTPS traffic costs CPU and requires managing certificates. Instead of teaching every backend to do that, you let the reverse proxy handle the encrypted connection with the client, decrypt it once, and talk to the backends over plain (but private) internal connections. This is called TLS termination, and it means you manage your certificate in one place instead of on every server. If you’re fuzzy on what that encryption layer even is, our piece on what a web server is sets up the foundation this builds on.

Load balancing

When you have several identical backend servers, the proxy can spread incoming requests across them so no single machine gets overwhelmed. This is load balancing, and a reverse proxy is the most natural place to do it — it’s already the thing every request flows through. (Load balancing is a big enough topic to deserve its own discussion, and it’s the very next thing worth reading after this.)

Caching

If many clients ask for the same thing — a popular image, a page that rarely changes — the proxy can keep a copy and answer directly without bothering the backend at all. That makes responses faster and takes load off your real servers. The line between content the proxy can safely cache and content it must always fetch fresh maps closely onto the difference between static and dynamic content, which is worth understanding before you tune caching.

Compression, headers, and tidying up

Because every response flows through it, the proxy is a convenient place to compress text responses, add security headers, strip sensitive internal headers the client shouldn’t see, and generally normalize what goes out the door — without touching the application code at all.

Hiding and protecting the backends

The backends never expose their real addresses to the internet. They can sit on a private network, reachable only by the proxy, which dramatically shrinks the attack surface. The proxy becomes the one hardened, watched, public-facing door — and everything valuable hides behind it.

Forward proxy vs reverse proxy, side by side

These two get mixed up constantly, so it’s worth laying them next to each other plainly. They’re built from the same idea but point in opposite directions.

FORWARD PROXY                         REVERSE PROXY
(stands in for clients)               (stands in for servers)

 client ─┐                                         ┌─ server
 client ─┼─► [proxy] ─► internet      internet ─► [proxy] ─┼─ server
 client ─┘                                         └─ server

 hides WHO is asking                   hides WHAT is answering
 lives near the users                  lives near the servers

• A forward proxy is configured by clients, knows about the clients, and reaches out to the wide internet on their behalf. Companies and schools use them to filter or monitor outbound traffic; individuals sometimes use them for privacy.
• A reverse proxy is configured by the people who run the servers, knows about the backends, and receives traffic from the wide internet on their behalf. Websites use them for everything we listed above.

If you only remember one line: a forward proxy protects and represents the clients; a reverse proxy protects and represents the servers.

Why almost every serious site runs behind one

Once a project grows past a single small server, a reverse proxy stops being optional and starts being obvious. You want HTTPS handled in one place. You want to add a second app server without changing your domain or your visitors’ experience. You want to serve images from a different machine than your application. You want a single front door you can monitor, rate-limit, and harden. Every one of those needs lands naturally on the same component.

It also gives you room to change the inside without disturbing the outside. You can swap a backend, move a service to a new machine, split one server into three, or roll out a new version gradually — and as long as the proxy keeps presenting the same stable address to the world, visitors never notice. That separation between the public face and the private machinery is one of the most useful ideas in all of server architecture, and the reverse proxy is where it lives. If the underlying request-and-response mechanics still feel hazy, our walkthrough of how web servers work is a good companion to this one.

Wrapping up

Here’s the whole picture in one place:

• A reverse proxy is a server that sits in front of your backend servers, receiving every request first and deciding what to do with it.
• It makes many servers look like one to the outside world — clients see a single stable address and never learn what’s really behind it.
• “Reverse” just means it stands in for the servers, while a forward proxy stands in for the clients. Same idea, opposite side.
• In one well-placed component it can handle routing, TLS/HTTPS termination, load balancing, caching, compression, and protection of the backends.
• Because it’s the single point every request flows through, it’s the natural home for anything that should apply to all traffic — which is why nearly every serious website runs behind one.

The most important of those jobs deserves a closer look on its own, so next we’ll dig into load balancing — how a proxy spreads traffic across many servers so a site can keep serving when one machine gets busy, slow, or falls over entirely.