A reverse proxy is a server that sits in front of your backend servers and receives client requests on their behalf. Clients talk only to the proxy; the proxy forwards each request to a backend, gets the response and sends it back. The client never needs to know which (or how many) servers are behind it. Examples: Nginx, HAProxy, Envoy, Traefik, and cloud load balancers.
In simple words
Think of a hotel reception. Guests never walk straight into the kitchen or laundry; they talk to reception, which passes requests to the right department and hands back the result. Guests don't even know how many staff are behind the desk. Reception is the reverse proxy.
Same idea, opposite sides: a forward proxy hides the clients, a reverse proxy hides and protects the servers.
Forward Proxy vs Reverse Proxy
Forward proxy: acts for CLIENTS Reverse proxy: acts for SERVERS
client A \ / server 1
client B --> [ forward proxy ] --> internet --> [ reverse proxy ] -- server 2
client C / \ server 3
hides/controls the clients hides/protects the servers
e.g. corporate proxy, VPN-ish filtering e.g. Nginx in front of an app
Same mechanism (a middleman that forwards HTTP), opposite side. A forward proxy is configured by or for the client (office networks, content filtering, anonymity). A reverse proxy is set up by the website owner in front of their servers.
Why It Exists
Load balancing: spread requests across many backends (a load balancer is a kind of reverse proxy).
TLS termination: handle HTTPS once at the edge so backends deal with plain HTTP on a private network.
Security: backends are not exposed directly; the proxy can block bad traffic, enforce limits, and hide internal topology.
Caching and compression: serve repeated responses from cache and gzip/brotli responses.
Routing: send /api/* to one service and /static/* to another behind a single domain.
How It Works
DNS for example.com points to the reverse proxy.
The proxy accepts the connection (terminating TLS), reads the request, and picks a backend by its rules (path, host, header, load-balancing algorithm, health).
It forwards the request, often adding headers such as X-Forwarded-For (the real client IP) and X-Forwarded-Proto.
It returns the backend's response, optionally caching or compressing it.
Reverse Proxy vs Load Balancer vs API Gateway
They overlap. A reverse proxy is the general pattern. A load balancer is a reverse proxy focused on spreading load and health checking. An API gateway is a reverse proxy focused on APIs: authentication, rate limiting, request transformation, routing to microservices. One product (Nginx, Envoy) can do all three.
Key Pointers
Reverse proxy = in front of servers, for the servers. Forward proxy = in front of clients, for the clients.
Common jobs: TLS termination, load balancing, caching, compression, routing, protection.
Behind a proxy, the backend sees the proxy's IP; use X-Forwarded-For (from a trusted proxy only) for the client IP.
It must itself be redundant, or it becomes a single point of failure.
Follow-up Questions
Isn't a reverse proxy a single point of failure?
Only if you run one. Run several behind DNS or a floating/anycast IP (or use a managed cloud load balancer, which is redundant internally).
Why terminate TLS at the proxy?
Certificates and TLS configuration live in one place, backends save CPU, and the proxy can inspect HTTP for routing. If the internal network isn't trusted, re-encrypt from proxy to backend (or use mTLS).
Can a reverse proxy cache API responses?
Yes, for cacheable ones (GET, public, with proper Cache-Control), which can take huge load off backends. Personalised responses need the user in the cache key or must not be cached.