What is a Reverse Proxy?

When you visit a busy website, you're almost never talking to its application server directly. There's something in front — a reverse proxy — taking your request first, then passing it along. It's one of the most useful pieces of web infrastructure, and the source of errors like 502 and 504 when it can't reach what's behind it. Let's demystify it.

What a reverse proxy is

A reverse proxy is a server that sits in front of your application servers and forwards client requests to them. To the outside world, the reverse proxy is your site; behind the scenes, it routes traffic to one or more backends.

Client ──► Reverse proxy ──► Your app server(s)

Common examples: Nginx, a cloud load balancer, or a CDN acting as the front layer.

Forward vs reverse proxy

The names confuse people. The difference is which side it works for:

	Forward proxy	Reverse proxy
Sits in front of	The client	The server
Works for	Users (hiding/filtering them)	The website (protecting/serving it)
Example	A corporate web filter, a VPN	Nginx in front of your app

A forward proxy represents the client (e.g. your company's outbound filter). A reverse proxy represents the server — it's the website's front door.

What it does for you

A reverse proxy quietly handles a lot:

Job	What it gives you
Load balancing	Spread traffic across many backends (more here)
TLS termination	Handle HTTPS in one place
Caching	Serve cached responses without hitting the app
Compression	Gzip/Brotli responses on the way out
Security	Hide backends, filter bad traffic, rate-limit
Routing	Send `/api` to one service, `/` to another

Centralising all that in front of your app keeps the backends simpler and the whole system more flexible.

Why nearly everyone uses one

A reverse proxy lets you:

Add or remove backend servers without clients noticing (great for scaling and deploys).
Terminate TLS once instead of in every app.
Cache and compress centrally.
Hide your infrastructure — clients only see the proxy, not your real servers.
Apply security rules (WAF, rate-limiting) at the edge.

It's the natural place to put cross-cutting concerns, which is why it's nearly universal.

The flip side: it's a failure point too

Because everything flows through it, the reverse proxy is also where certain errors originate:

502 Bad Gateway — the proxy reached a backend but got no valid response (backend down).
504 Gateway Timeout — the backend was too slow to answer.

A debugging tip: when you see a 502 or 504, that's the reverse proxy telling you about the backend behind it — so look past the proxy at your app, not at the proxy itself.

The bottom line

	In one line
What	A server in front of your app that forwards requests to it.
vs forward proxy	Reverse works for the server; forward works for the client.
Does	Load balancing, TLS, caching, compression, security, routing.
Watch	502/504 from it point at the backend behind it.

A reverse proxy is the front door, traffic cop, and security guard for your servers all in one. It's why scaling, HTTPS, and caching are manageable — and knowing it's there makes proxy-origin errors much easier to diagnose.