Quick answer
A reverse proxy is a server that receives requests intended for your application, then decides what to do with them — serve from cache, block, challenge, or forward to one of your origin servers. To the visitor it looks like the website itself; your actual servers stay unpublished behind it. Nearly every CDN, WAF and load balancer is a reverse proxy with a particular emphasis, which is why one system can be all three.
Forward proxy vs. reverse proxy
Both sit in the middle of a connection, but they act for opposite parties. A forward proxy acts for the client: your browser sends requests through it, and the destination server sees the proxy's address instead of yours. A VPN or a corporate web filter is a forward proxy.
A reverse proxy acts for the server: visitors address it directly, believing it to be the site, and it decides what reaches the real infrastructure behind. The client usually has no idea it exists.
| Forward proxy | Reverse proxy | |
|---|---|---|
| Acts for | The client | The server |
| Hides | The visitor from the site | The infrastructure from the visitor |
| Configured by | The user or their network | The site operator |
| Typical use | VPN, corporate filtering | CDN, WAF, load balancer |
What a reverse proxy does with a request
- Terminates TLS, so certificates are managed in one place rather than on every backend
- Inspects the request and may block, challenge or rate limit it before your application is involved
- Serves it from cache if a fresh copy exists, without contacting the origin at all
- Chooses a backend and forwards it, balancing load and skipping unhealthy servers
- Rewrites headers, compresses responses and normalises anything the origin should not have to handle
Why hiding the origin matters
Once traffic goes through a reverse proxy, your origin only ever needs to accept connections from the proxy. Everything else can be firewalled off entirely — which means an attacker who wants to reach your application has to go through the layer designed to stop them.
The protection collapses if the origin address leaks, and it leaks more often than people expect: old DNS records that were never deleted, certificate transparency logs, mail headers sent by the same host, error pages that print an internal hostname, or a subdomain that was never proxied.
Keeping the visitor's real address
Because the proxy makes the connection to your origin, your application sees the proxy's address as the client. The visitor's real address is passed along in a header instead — usually `X-Forwarded-For` or a provider-specific equivalent — and your application has to be configured to trust and read it.
This needs care. Any client can send an `X-Forwarded-For` header, so it must only be trusted when the connection genuinely came from your proxy. Otherwise anyone can claim any address and defeat every rate limit and geo rule you have.
Frequently asked questions
Last updated