What Is a Reverse Proxy? How It Works, Explained

A reverse proxy is a server that sits in front of one or more backend servers, receiving client requests on their behalf and forwarding them onward. From the outside, clients only ever talk to the reverse proxy — they never see, and don’t need to know, how many backend servers actually exist or where they’re located. The proxy decides where each request goes, and it can transform the request or response along the way.

This is different from the more familiar forward proxy, which sits in front of clients rather than servers.

Forward proxy vs reverse proxy

	Forward proxy	Reverse proxy
Sits in front of	Clients	Servers
Who it’s transparent to	The destination server (doesn’t see the real client)	The client (doesn’t see the real server)
Typical use	Corporate network egress, content filtering, anonymizing outbound traffic	Load balancing, TLS termination, caching, hiding backend architecture
Configured by	The client (or client’s network)	The server operator

A forward proxy hides the client from the server it’s talking to. A reverse proxy hides the server — or servers — from the client. Both route traffic through a middle hop, but the direction of who’s being protected is reversed.

What a reverse proxy actually does

A single reverse proxy layer commonly handles several jobs that would otherwise need to be duplicated across every backend instance:

• TLS termination — the proxy holds the certificate and decrypts incoming HTTPS traffic, forwarding plain HTTP to backend servers over a trusted internal network. This centralizes certificate management instead of installing certs on every backend.
• Load balancing — distributing incoming requests across multiple backend instances so no single server gets overwhelmed. See what a load balancer is for the routing algorithms and health-check mechanics involved; a reverse proxy and a load balancer are frequently the same piece of software wearing two hats.
• Caching — storing responses for frequently requested content so repeat requests are served without hitting the backend at all. This is the same principle a CDN applies at a larger, geographically distributed scale.
• Compression — gzip or Brotli-compressing responses before they leave the proxy, so backend servers don’t each need to do it.
• Request routing — sending /api/* to one backend and /static/* to another, based on path, hostname, or headers, without the client knowing multiple services exist behind the single address.
• Security filtering — rejecting malformed requests, rate-limiting abusive clients, and masking internal server details like software versions and internal hostnames.

Where it sits in the request path

A typical request through a reverse-proxied system looks like this: the client resolves a hostname via DNS to the proxy’s public IP, opens a TLS connection to the proxy, and sends the request. The proxy decrypts it, decides which backend should handle it, and forwards the request over the internal network — often re-encrypting or leaving it plain depending on the trust boundary. The backend’s response flows back through the same path in reverse.

In a microservices architecture, this pattern often scales into a service mesh, where every service gets its own lightweight proxy (a sidecar) handling service-to-service traffic, retries, and encryption — effectively a reverse proxy per service instead of one shared at the edge. The single-proxy pattern described here is the simpler, more common starting point, and it’s often all a smaller system needs.

Reverse proxies and zero trust

Because a reverse proxy already intercepts every request before it reaches a backend, it’s a natural enforcement point for authentication and authorization checks — verifying identity and device posture on each request rather than trusting anything inside a network perimeter. This is the architectural pattern behind zero trust security: the proxy (or a purpose-built access proxy) becomes the checkpoint every request must clear, regardless of whether the request originated inside or outside the traditional network boundary.

Common failure modes

A reverse proxy that’s misconfigured becomes a single point of failure for everything behind it — if it goes down, every backend it fronts becomes unreachable even if those backends are perfectly healthy. Production deployments typically run multiple proxy instances behind their own load-balancing layer (often DNS-based or using a floating IP) specifically to avoid this.

Header handling is another common source of bugs. A reverse proxy needs to explicitly forward or rewrite headers like X-Forwarded-For and X-Forwarded-Proto so backend applications can still see the original client IP and protocol — without this, backend logs and IP-based rate limiting see only the proxy’s own address, not the real client’s.

Timeout mismatches between the proxy and the backend cause a subtler class of problem. If a backend’s request-handling timeout is longer than the proxy’s, the proxy may give up and return an error to the client while the backend is still processing the request — leaving the client seeing a failure for work that eventually succeeded server-side. Keeping timeout values consistent across every hop in the chain, from the client-facing proxy timeout through any internal service timeouts, is one of the easier things to overlook when adding a reverse proxy to an existing system.

Reverse proxies in modern deployment platforms

Many managed hosting and edge platforms bundle reverse proxy behavior into the deployment itself rather than requiring you to run and configure the software directly. Static sites and serverless functions deployed behind a managed edge network get TLS termination, caching, and routing handled automatically, which is part of why deploying something like an Astro site to Cloudflare Pages doesn’t require separately standing up and maintaining nginx or a similar reverse proxy — the platform’s edge layer already fills that role.

The takeaway

A reverse proxy is the single point of contact clients see, standing in front of backend servers to terminate TLS, balance load, cache responses, and enforce security policy before a request ever reaches application code. It’s a forward proxy’s mirror image — protecting servers from clients instead of clients from servers — and it’s the architectural building block that load balancers, CDNs, and service meshes all extend in their own direction.