Reverse Proxy
A server that sits in front of your backend servers and forwards client requests to them. Handles SSL termination, caching, and load balancing.
What is Reverse Proxy?
In short
A reverse proxy is a server that sits in front of one or more backend servers and receives client requests on their behalf, then forwards each request to the right backend and returns the response to the client. It hides your backend topology and centralizes work like TLS termination, caching, compression, and load balancing in one place.
What a reverse proxy actually is
A normal (forward) proxy sits in front of clients and represents them when they reach out to the wider internet, the way a corporate proxy filters employee traffic. A reverse proxy is the mirror image: it sits in front of servers and represents them to the public. Clients think they are talking to the application; they are really talking to the proxy, which decides what to do with each request.
From the outside, all you see is the proxy's IP address and hostname. Behind it there might be one server, or fifty, written in different languages, running on different ports and machines. The client never learns any of that. This indirection is the whole point: the proxy becomes a single, stable front door, and the messy details of how the backend is built can change freely behind it.
Reverse proxies operate at the application layer (HTTP/HTTPS) or the transport layer (TCP/UDP). Most web setups use an HTTP reverse proxy because it can read headers, paths, and cookies, which lets it route and cache intelligently rather than just shoveling bytes.
How it works under the hood
When a request arrives, the proxy terminates the client's TCP connection and, for HTTPS, completes the TLS handshake itself. This is called TLS termination: the proxy holds the certificate and private key, decrypts the traffic, and your backend servers can speak plain HTTP internally without each one managing its own certificate.
The proxy then inspects the request and picks a backend, often called an upstream. Routing rules can be based on the URL path (send /api to the API service, /static to a file server), the hostname (api.example.com versus shop.example.com), headers, or a load-balancing algorithm such as round robin or least connections. It rewrites or adds headers like X-Forwarded-For and X-Forwarded-Proto so the backend still knows the real client IP and original protocol.
It opens its own connection to the chosen upstream, forwards the request, reads the response, and streams it back to the client. Along the way it can cache responses, compress them with gzip or Brotli, buffer slow clients so backend workers are freed quickly, and retry against a different backend if one fails. Connection reuse (keep-alive pools to upstreams) means the proxy avoids paying TCP and TLS setup costs on every request.
When to use one and the trade-offs
Reach for a reverse proxy the moment you have more than one backend instance, or you want to centralize cross-cutting concerns. It is the natural place to do TLS termination, gzip compression, request rate limiting, IP allow/deny lists, basic auth, response caching, and graceful failover. Putting these in the proxy means you write the logic once instead of in every service.
The trade-offs are real. The proxy is a new hop, so it adds a small amount of latency, usually well under a millisecond for software like NGINX but non-zero. It is also a single point of failure: if the proxy goes down, everything behind it is unreachable, so production setups run several proxy instances behind a load balancer or DNS round robin. Holding the TLS keys at the proxy concentrates a security-sensitive asset in one tier, which you must lock down.
There is overlap with the term load balancer, and the distinction is fuzzy. A reverse proxy can load balance, and most load balancers are implemented as reverse proxies. The useful mental split: a load balancer's job is spreading traffic across identical instances; a reverse proxy's broader job is being a smart gateway that may route, cache, terminate TLS, and rewrite, in addition to balancing.
A concrete example
Say you run a shop with a Next.js frontend on port 3000, a Node API on port 4000, and a Python image service on port 5000. You point your domain at one NGINX reverse proxy on ports 80 and 443. NGINX holds the Let's Encrypt certificate and terminates TLS.
A request for shop.com/ goes to the frontend, shop.com/api/orders goes to the Node API, and shop.com/images/* goes to the Python service, all decided by NGINX location blocks. NGINX caches the image responses for an hour, gzips HTML and JSON, adds X-Forwarded-For so the API logs see real client IPs, and runs two copies of the Node API in a round-robin upstream so a deploy of one copy never takes the site down.
To the customer, it is one origin on one HTTPS hostname. To you, the backend is three separate codebases you can scale, restart, and rewrite independently. That separation is exactly what the reverse proxy buys you.
Where it is used in production
NGINX
The most widely deployed reverse proxy, used for TLS termination, path-based routing, caching, and load balancing in front of app servers.
Cloudflare
Runs as a globally distributed reverse proxy in front of millions of sites, adding TLS, caching, DDoS protection, and edge routing.
AWS Application Load Balancer
A managed Layer 7 reverse proxy that terminates TLS and routes by path or host to target groups of EC2 instances or containers.
Envoy
A high-performance reverse proxy that powers service meshes like Istio, handling routing, retries, and observability between microservices.
Frequently asked questions
- What is the difference between a forward proxy and a reverse proxy?
- A forward proxy sits in front of clients and acts on their behalf to reach the internet, often for filtering or anonymity. A reverse proxy sits in front of servers and acts on their behalf, taking client requests and forwarding them to the right backend. Same proxy idea, opposite side of the connection.
- Is a reverse proxy the same as a load balancer?
- They overlap heavily. A load balancer's specific job is distributing traffic across identical instances, and it is usually built as a reverse proxy. A reverse proxy is the broader concept: it can also do TLS termination, caching, routing by URL, and header rewriting. Most load balancers are reverse proxies, but not every reverse proxy is purely a load balancer.
- What is TLS termination at a reverse proxy?
- It means the proxy holds the SSL/TLS certificate and decrypts incoming HTTPS traffic, so your backend servers can communicate over plain HTTP internally. This centralizes certificate management in one tier instead of every backend handling its own, though it does concentrate the private key at the proxy.
- Does a reverse proxy slow down my application?
- It adds one extra network hop, which is real but tiny, typically under a millisecond with software like NGINX or Envoy. In practice it often makes things faster because it caches responses, reuses upstream connections, compresses payloads, and buffers slow clients so backend workers are freed sooner.
- How do I keep my backend's real client IP when using a reverse proxy?
- The proxy adds headers like X-Forwarded-For and X-Forwarded-Proto carrying the original client IP and protocol. Your backend must be configured to trust and read those headers, and you should only trust them from your own proxy so clients cannot forge them.
Learn Reverse Proxy hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Reverse Proxy as part of a larger topic.
Server-Side Caching
Caching at the server and infrastructure level, reverse proxies, CDNs, and full-page caching
foundation · caching strategies
Varnish Cache
The HTTP accelerator that sits in front of your web server, caching full HTTP responses at wire speed
foundation · caching strategies
Path-Based Routing
Routing requests to different backends based on the URL path, the backbone of microservices
foundation · load balancing proxies
Host-Based Routing
Route traffic to different backend services based on the hostname in the request
foundation · load balancing proxies
See also
Related glossary terms you might want to look up next.
Proxy
An intermediary server that sits between the client and the destination server. Forward proxies act on behalf of clients; reverse proxies act on behalf of servers.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
CDN
A network of servers distributed globally that caches content close to users. Netflix uses CDNs to stream video from servers near you, not from one central location.
DNS
The phonebook of the internet. Translates human-readable domain names (google.com) into IP addresses that computers understand.
DNS Record Types
Different types of DNS records map domains to resources: A records point to IPs, CNAME aliases one domain to another, MX routes email, TXT stores verification data.
Forward Proxy
A proxy that sits in front of clients and forwards their requests to the internet. Used for anonymity, content filtering, and bypassing geo-restrictions.