A reverse proxy is a server that sits in front of a website and handles incoming requests on the site’s behalf. Visitors talk to the reverse proxy; the reverse proxy talks to the real application server behind it. To the visitor it looks like they are talking to your site directly.
If a forward proxy stands in for the visitor, a reverse proxy stands in for the site.
Why you would want one
Reverse proxies can do five useful things at once, which is why most large websites have one:
- Terminate TLS. The reverse proxy handles HTTPS with the visitor and forwards the request to your app internally, often as plain HTTP on a private network. You update one certificate, not one per service.
- Load balance. Requests fan out across a pool of application servers. If one dies, the reverse proxy stops routing to it until it comes back.
- Cache. Static assets — images, CSS, JavaScript — get served straight from the reverse proxy, sparing the application from doing the same work again.
- Compress and rewrite. Gzip or Brotli compression, header rewrites, redirect rules — all live in the reverse proxy so your app doesn’t have to.
- Filter and protect. A reverse proxy is where you enforce rate limits, block bad IPs, and add DDoS protection.
You can see the fifth job from the visitor’s side. umingle.com sits behind Cloudflare, and its rules refuse datacenter networks. When we opened it through AnyProxy’s Frankfurt server on 15 October 2026, Cloudflare answered on the site’s behalf and the site’s own server never saw the request.
Caption: umingle.com through AnyProxy Frankfurt, 15 October 2026. The block page comes from Cloudflare, the site’s reverse proxy.
Reverse proxy vs load balancer
An HTTP load balancer is a reverse proxy whose main job is picking which backend server takes each request. Not every reverse proxy is primarily a load balancer, and some load balancers work lower down, forwarding raw TCP connections or packets rather than HTTP requests. In practice modern tools do both, and the distinction is mostly historical.
Reverse proxy vs forward proxy
| Forward proxy (e.g. AnyProxy) | Reverse proxy (e.g. Cloudflare) | |
|---|---|---|
| Stands in for | The client | The server |
| Sits between | You and the internet | The internet and a website |
| You use it to | Open blocked sites | You don’t — the site uses one |
| Common examples | AnyProxy, Squid, corporate web filters | Nginx, Cloudflare, HAProxy |
When to add one to your site
You almost certainly already have a reverse proxy the moment you put a site on the internet, even if you didn’t call it that.
- Deploy on Vercel, Netlify, Cloudflare Pages — you’re using their reverse proxy.
- Deploy on AWS with an Application Load Balancer — the ALB is a reverse proxy.
- Run Docker Compose with an Nginx container in front — that Nginx is a reverse proxy.
The moment your site has more than one instance, needs TLS, or serves static assets, adding an explicit reverse proxy (Nginx, Caddy, or a managed CDN) is the standard move.
The one gotcha
A reverse proxy hides the visitor’s IP from your application unless you configure the app to look for it. You need to trust the X-Forwarded-For or Forwarded header that the proxy sets, and configure your app to read the visitor’s real address from there. Otherwise every request looks like it came from the proxy — which will confuse rate limiting, logging, and geolocation.
Set this up once at deploy time. Most frameworks have a setting or middleware for it (Rails’ ActionDispatch::RemoteIp, Express’s trust proxy setting, Werkzeug’s ProxyFix for Flask, and so on). Only trust these headers from your own proxy: a visitor can send a fake X-Forwarded-For of their own.
Related reading
- What is a proxy server? — the forward-proxy sibling article.
- Proxy vs VPN — for when the tab-vs-device distinction matters.