---
title: What is a Reverse Proxy?
description: A reverse proxy is the front door to your servers — handling traffic before it ever reaches your app. Here's what it does, why nearly every serious site uses one, and how it differs from a forward proxy.
canonical: https://watchfor.io/blog/reverse-proxy-explained
---

# What is a Reverse Proxy?

2026-01-01 · WatchFor Team · Networking · networking, web, basics

A reverse proxy is the front door to your servers — handling traffic before it ever reaches your app. Here's what it does, why nearly every serious site uses one, and how it differs from a forward 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](/blog/502-bad-gateway) and [504](/blog/504-gateway-timeout) 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](/blog/what-is-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](/blog/load-balancing-explained)) |
| **TLS termination** | Handle [HTTPS](/blog/how-https-works) in one place |
| **Caching** | Serve cached responses without hitting the app |
| **Compression** | [Gzip/Brotli](/blog/gzip-vs-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](/blog/waf-explained), 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](/blog/502-bad-gateway)** — the proxy reached a backend but got no valid response (backend down).
- **[504 Gateway Timeout](/blog/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.

Related: [load balancing](/blog/load-balancing-explained), [502 Bad Gateway](/blog/502-bad-gateway), [what is a CDN?](/blog/what-is-a-cdn).

---

Canonical page: https://watchfor.io/blog/reverse-proxy-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt