What is a Reverse Proxy?

Table of Contents +

Here’s something that might surprise you. When you open a big website and your request hits “the server”, you’re almost never talking to the real server doing the work.

There’s usually something sitting in front of the real servers.
That something catches your request first, then decides where it should really go.
Your browser thinks it’s talking to one machine. Behind that one machine, there could be a hundred.

That gatekeeper in front is called a reverse proxy. So let’s see what it is, what it does, and why almost every serious system has one.

🚪 What is a Reverse Proxy?

Let’s define it clearly first, then unpack it.

A reverse proxy is a server that sits in front of your backend servers. It receives requests from clients, forwards them to the right backend server, then sends that server’s response back to the client.
A backend server is just the machine that actually does the real work, like running your app code or fetching data. (We’ll call these “backends” for short.)
A client is whoever is making the request, usually a user’s browser or a mobile app.

So the flow is simple to picture. The client never talks to a backend directly. It talks to the reverse proxy, and the reverse proxy does the talking on the backend’s behalf.

Think of it like a receptionist at a big office.
You don’t walk straight to the person you need. You tell the receptionist, and they send you to the right desk.
The receptionist is the single front door. Everyone goes through them.

That single front door idea is the heart of it. One entry point, many servers hidden behind it.

🔁 Forward Proxy vs Reverse Proxy

People mix these two up all the time, so let’s pin both down. The trick is to ask one question: who is it standing in front of?

A forward proxy sits in front of clients. It hides the clients from the server. The server sees the proxy, not the real user.
A reverse proxy sits in front of servers. It hides the servers from the clients. The client sees the proxy, not the real backend.

A quick way to remember it. A forward proxy works for the people sending requests. A reverse proxy works for the people receiving them.

A forward proxy is like a middleman you hire to make calls on your behalf, so the other side never sees your number. A company VPN that routes your traffic is a forward proxy.
A reverse proxy is like that office receptionist again. Visitors reach the receptionist, and they never see who’s actually working in the back rooms.

Here’s the side-by-side so it sticks.

Question	Forward Proxy	Reverse Proxy
Sits in front of	Clients (users)	Servers (backends)
Hides	The client from the server	The servers from the client
Works for	The user sending the request	The website receiving the request
Typical use	VPN, content filtering, anonymity	Load balancing, SSL, caching, security
Who sets it up	The user or their network	The website owner

One-line memory hook

Forward proxy = in front of clients. Reverse proxy = in front of servers. Same word “proxy”, opposite ends of the conversation.

🧩 What a Reverse Proxy Does

A reverse proxy isn’t just a pass-through. It’s a great spot to handle the jobs that every backend would otherwise have to do on its own. Here’s what it commonly takes care of.

Load balancing. It spreads incoming requests across many backend servers, so no single one gets crushed.
SSL termination. SSL termination means the proxy handles the encryption and decryption for HTTPS, so your backends don’t have to. The proxy takes the secure traffic, unlocks it, and passes plain traffic to the backends behind it. (SSL is the security layer behind the lock icon in your browser.)
Caching. It can keep a copy of common responses and hand them back instantly, without bothering a backend at all.
Compression. It can shrink responses before sending them, so pages load faster for the user.
Hiding backend details. Clients only ever see the proxy. They never learn how many servers you run or what their addresses are.
Security and filtering. It can block bad traffic, rate-limit abusers, and act as one shield in front of everything.

So instead of teaching every backend to do all this, you do it once, in one place. That’s the real win.

⚙️ How It Works

Let’s walk through a single request, step by step.

The client sends a request to your domain, say shop.com. That request lands on the reverse proxy, not a backend.
The proxy looks at the request. It might check the path, the headers, or how busy each backend is right now.
It picks a healthy backend and forwards the request along.
The backend does its work and sends the response back to the proxy.
The proxy returns that response to the client, who has no idea any of this happened.

Here’s the whole trip as a picture.

Notice how everything funnels through the proxy in both directions. The request goes in through it, and the response comes back out through it. That two-way control is exactly why the proxy is such a handy place to add caching, security, and the rest.

🔗 Reverse Proxy vs Load Balancer

This one trips up a lot of people, so let’s be careful.

A load balancer is a tool that spreads requests across many servers so the load stays even.
Load balancing is one of the jobs a reverse proxy often does. So a reverse proxy can act as a load balancer, but it usually does more on top of that.
A pure load balancer mainly cares about distributing traffic. A reverse proxy also handles SSL, caching, routing by path, and security.

So how do they relate? They overlap a lot, and in real life the lines blur.

Tools like Nginx and HAProxy can do both. You can run Nginx purely as a load balancer, or as a full reverse proxy that also balances load.
Think of it like a tool that can do many jobs. Load balancing is one setting on it, not the whole tool.

Don't say they're identical

“Reverse proxy” and “load balancer” are related but not the same. A load balancer is a focused job. A reverse proxy is the broader role that often includes that job, plus SSL, caching, and security.

⚡ Benefits

So why do almost all real systems put a reverse proxy out front? A few clear wins.

One entry point. Clients hit a single address. You can add, remove, or restart backends behind it, and nobody outside ever notices.
It offloads work from backends. SSL, caching, and compression all get handled at the proxy, so your backends stay lean and focused on real app logic.
It adds security and caching for free. Since every request passes through it, the proxy is the natural place to filter bad traffic and serve cached responses fast.
Flexibility. You can route different paths to different services. Send /api to one set of servers and /images to another, all from the same front door.

⚠️ Common Mistakes and Misconceptions

Let’s clear out the usual confusions before they take root.

“Forward proxy and reverse proxy are the same thing.” No. They’re opposites in direction. A forward proxy fronts clients, a reverse proxy fronts servers.
“A reverse proxy is exactly a load balancer.” Not quite. Load balancing is just one thing it can do. A reverse proxy also handles SSL, caching, routing, and security.
“The proxy can never be a weak point.” Careful here. Since everything flows through it, the reverse proxy can become a single point of failure. A single point of failure is one part whose breakdown takes the whole system down. If the proxy dies and you only have one, your whole site goes down. That’s why real setups run more than one.
“The reverse proxy runs my app code.” It doesn’t. It forwards requests to the backends that run the code. The proxy itself just directs traffic and handles those edge jobs.

🛠️ Design Challenge

Try this one on your own to test yourself.

Imagine Alex is building an online store, shop.com. There are three backend servers running the app, and the site needs HTTPS, fast image loading, and protection from abusive traffic. Sketch out where a reverse proxy fits.

Where does the client’s request land first?
Which jobs would you push onto the proxy instead of the backends?
What would happen if that single proxy crashed, and how would you avoid it?

Draw the boxes and arrows. If you can explain why each job belongs on the proxy, you’ve really got it.

🧩 What You’ve Learned

You can now explain what a reverse proxy is and why systems lean on it. Here’s the recap.

✅ A reverse proxy is a server that sits in front of backends, forwarding requests and returning responses.
✅ A forward proxy fronts clients, a reverse proxy fronts servers. Opposite directions.
✅ It handles load balancing, SSL termination, caching, compression, hiding backends, and security.
✅ Load balancing is one job a reverse proxy does, so it overlaps with a load balancer but isn’t identical.
✅ It gives you one entry point and offloads work from backends, but a single proxy can be a point of failure.

Check Your Knowledge

Test what you learned. Pick an answer for each question, then click Check.

🚀 What’s Next?

Now that you know the role, let’s see it in action and where it grows into bigger patterns.

Nginx as a Load Balancer shows how a real reverse proxy spreads traffic across backends.
API Gateway takes the reverse proxy idea further for managing many services behind one door.

Previous Sticky Sessions Explained Next Nginx as a Load Balancer

Share & Connect

Share on LinkedIn