We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningFoundation · Load Balancing & Proxies
A server in front of your web servers that receives every request first, passes it to one of them and returns the answer. It handles TLS, load balancing, caching and routing, and hides the servers behind it.
In short
A reverse proxy is a server that sits in front of your web servers and receives every request from the internet first. It decides which server should answer, passes the request on, and sends the answer back, so visitors only ever talk to the proxy. nginx, HAProxy, Caddy, Traefik, Envoy and Cloudflare are common examples.
In short
A reverse proxy is a server that sits in front of your web servers and receives every request from the internet first. It decides which server should answer, passes the request on, and sends the answer back, so visitors only ever talk to the proxy. nginx, HAProxy, Caddy, Traefik, Envoy and Cloudflare are common examples.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Reverse Proxy across a run of lessons, not one page. These 4 alone are about 127 minutes of step-by-step reading, every one with a quiz.
An intermediary that receives requests on behalf of servers, for TLS, routing, balancing, caching and protection.
Caching the finished response removes all the work, and one personalised element removes all the benefit.
The hit rate was 0.0 percent as the framework ships and 99.0 percent with one response header removed. At 80 percent of visitors cookied, 15,913 of 20,000 requests skipped the cache.
Path-based routing for microservices request routing, tested on real nginx, Envoy and HAProxy: nginx location order, ALB path rules, Ingress, path vs host.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Reverse Proxypay once,
yours for life
A reverse proxy is a server that stands between the internet and your own servers. Every request a visitor sends arrives at the proxy first. The proxy picks one of your servers, forwards the request to it, waits for the answer, and passes that answer back. The visitor never connects to your servers directly and usually cannot even reach them.
A few words first. A server here is just a program that answers requests over the network. A backend (or origin) is one of your own servers behind the proxy, the one that actually builds the page or runs the API. A request is one message, such as "give me /login". A header is a labelled line of extra information that travels with it, like Host: example.com.
Why put something in the middle at all? Because once every request passes through one place, you can do the shared jobs there, not in every server. The proxy can hold the HTTPS certificate and spread traffic across several copies of your app. It can keep a copy of pages that rarely change, block abusive clients, and hide how many servers you run. It also means you can add, remove or restart backends while visitors keep using the same single address.
Here is one request, from the visitor's browser to your app and back.
Step 4 is the one that surprises people. From the backend's point of view, every single connection comes from the proxy. The visitor's address only arrives inside a header, and only if the proxy chose to add it. My lab below shows exactly that.
Almost every job below is possible only because the proxy sees every request before your app does.
To check the claims on this page, I ran a real setup on 2026-10-04: nginx 1.26.3 in Docker, in front of two tiny Python backends on a private Docker network. Each backend answers with what it can see about the request: its own name, the address that connected to it, and the forwarding headers. Only the proxy publishes ports to my Mac (8080 for HTTP, 8443 for HTTPS, 8081 for a second variant). This is the whole proxy configuration:
nginx.conf
# The reverse proxy: one public address in front of two backends.
proxy_cache_path /var/cache/nginx/app keys_zone=app:10m max_size=50m;
upstream app {
zone backends 64k; # share the round-robin position between worker processes
server backend1:8000;
server backend2:8000;
}
server {
listen 80;
listen 443 ssl;
ssl_certificate /etc/nginx/tls/cert.pem;
ssl_certificate_key /etc/nginx/tls/key.pem;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location /report {
proxy_pass http://app;
proxy_cache app;
proxy_cache_use_stale error timeout http_502 http_503;
add_header X-Cache-Status $upstream_cache_status always;
}
location / {
proxy_pass http://app;
}
}
# The same proxy with one line changed: it overwrites X-Forwarded-For
# instead of appending to whatever the client sent.
server {
listen 81;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
location / {
proxy_pass http://app;
}
}Round robin across the two backends, then what one backend sees (run on 2026-10-04)
$ for i in 1 2 3 4; do curl -s localhost:8080/whoami | python3 -c "import sys,json;print(json.load(sys.stdin)[\"served_by\"])"; done
backend2
backend1
backend2
backend1
$ curl -s localhost:8080/whoami
{"served_by": "backend2", "peer": "172.18.0.4", "Host": "localhost", "X-Forwarded-For": "192.168.65.1", "X-Real-IP": "192.168.65.1", "X-Forwarded-Proto": "http"}
$ curl -s -m 3 localhost:8000/whoami || echo "connection refused: nothing listens on the host"
connection refused: nothing listens on the hostRead the second output slowly. The peer, the address the backend's connection actually came from, is 172.18.0.4: that is the nginx container, on every request. nginx saw my Mac as 192.168.65.1, Docker Desktop's gateway. That address reaches the backend only through X-Forwarded-For and X-Real-IP, the headers my config told nginx to add. And the backends cannot be reached from outside at all: they have no published port.
One thing I did not expect. My first run had the same config without the zone line, and six requests in a row all went to backend1. nginx was running 10 worker processes, one per CPU. Without a shared memory zone, each worker keeps its own place in the rotation. The nginx docs say the zone directive is what shares an upstream group's run-time state between workers. With zone added, the rotation alternated as above.
X-Forwarded-For is the usual way a proxy tells the backend who the visitor was. nginx's $proxy_add_x_forwarded_for variable, which almost every tutorial uses, takes whatever X-Forwarded-For the client sent and appends the client's address to the end. So I sent a forged one:
A client forges the header, against the appending proxy (8080) and the overwriting one (8081)
$ curl -s -H "X-Forwarded-For: 6.6.6.6" localhost:8080/whoami
{"served_by": "backend1", "peer": "172.18.0.4", "Host": "localhost", "X-Forwarded-For": "6.6.6.6, 192.168.65.1", "X-Real-IP": "192.168.65.1", "X-Forwarded-Proto": "http"}
$ curl -s -H "X-Forwarded-For: 6.6.6.6" localhost:8081/whoami
{"served_by": "backend2", "peer": "172.18.0.4", "Host": "localhost", "X-Forwarded-For": "192.168.65.1", "X-Real-IP": null, "X-Forwarded-Proto": null}Behind the appending proxy, the backend received "6.6.6.6, 192.168.65.1". Code that takes the first entry, a common shortcut, now believes the visitor is 6.6.6.6. A rate limit or an IP ban can be dodged with one header. The second server block sets the header to $remote_addr and throws the client's version away, and the forged value is gone.
The rule: your outermost proxy, the one that faces the internet, should overwrite these headers, not append to them. Proxies further inside can append, and your app should trust only the entries added by proxies you run, counting from the right. The second run shows one more thing. That server block did not set X-Real-IP or X-Forwarded-Proto, so the backend got nothing for them. A header the proxy does not set simply does not exist for the app.
Three more things from the same run. First, HTTPS ends at the proxy, and the backend is told about it only through X-Forwarded-Proto:
TLS ends at nginx; the backend gets plain HTTP plus a header
$ curl -sk -v https://localhost:8443/whoami 2>&1 | grep -E "^\* SSL connection|^\{\""
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
{"served_by": "backend1", "peer": "172.18.0.4", "Host": "localhost", "X-Forwarded-For": "192.168.65.1", "X-Real-IP": "192.168.65.1", "X-Forwarded-Proto": "https"}Caching: /report takes the backend 0.3 s to build and sends Cache-Control: max-age=60
$ for i in 1 2 3; do curl -s -o /dev/null -D - localhost:8080/report -w "time %{time_total}s\n" | grep -E "X-Cache-Status|time"; done
X-Cache-Status: MISS
time 0.309394s
X-Cache-Status: HIT
time 0.002187s
X-Cache-Status: HIT
time 0.002604sStop backend2, then backend1 too
$ docker stop -t 1 backend2 >/dev/null; for i in 1 2 3 4; do curl -s localhost:8080/whoami -w " %{http_code}\n" | python3 -c "import sys,json;l=sys.stdin.read().split();print(l[-1], json.loads(\" \".join(l[:-1]))[\"served_by\"])"; done
200 backend1
200 backend1
200 backend1
200 backend1
$ docker stop -t 1 backend1 >/dev/null; curl -s -o /dev/null -w "%{http_code}\n" localhost:8080/whoami; curl -s -o /dev/null -D - localhost:8080/report | grep -E "^HTTP|X-Cache"
502
HTTP/1.1 200 OK
X-Cache-Status: STALE
$ docker exec proxy grep -m2 -E "connect\(\) failed|no live upstreams" /var/log/nginx/error.log
2026/10/04 07:41:08 [error] 403#403: *27 connect() failed (113: No route to host) while connecting to upstream, client: 192.168.65.1, server: , request: "GET /whoami HTTP/1.1", upstream: "http://172.18.0.3:8000/whoami", host: "localhost:8080"
2026/10/04 07:41:48 [error] 403#403: *34 connect() failed (113: No route to host) while connecting to upstream, client: 192.168.65.1, server: , request: "GET /whoami HTTP/1.1", upstream: "http://172.18.0.2:8000/whoami", host: "localhost:8080"The first /report request missed the cache and took 0.31 seconds, the backend's built-in delay. The next two were served from nginx's cache in about 2 milliseconds and never reached a backend. nginx honours the backend's own Cache-Control header, so the app decides how long a page may be reused.
When backend2 stopped, every request still returned 200 from backend1. nginx's error log shows why the visitor never noticed. Its connection to backend2 failed with "No route to host". nginx then retried the same request on the other server, its default for connection errors. When both backends were gone, /whoami returned 502 Bad Gateway, the proxy's way of saying it could not get an answer from behind it. But /report still returned 200, marked STALE. The cached copy was past its 60 seconds by then. proxy_cache_use_stale told nginx that an old page is better than an error.
A load balancer is anything that spreads requests across several servers. A reverse proxy is a server that receives requests on your servers' behalf. The two overlap a lot. Most reverse proxies, nginx included, are also load balancers. Many load balancers, such as AWS's Application Load Balancer, are reverse proxies that read HTTP.
The useful difference is which layer they work at. A layer 4 load balancer moves TCP connections and never reads the request. It is fast and works for any protocol, but it cannot route by path or cache anything. A reverse proxy works at layer 7, the HTTP level, so it can read the path, headers and cookies and act on them. A reverse proxy with one backend and no balancing, used only for TLS and caching, is still a reverse proxy.
In production they usually stack. A cloud load balancer spreads traffic over two or more proxies, so no single proxy can take everything down.
Both are a server in the middle. The difference is whose side it is on. A forward proxy is set up by the clients' organisation. For example, an office network sends every outgoing request through one proxy to filter or log it. Websites see the proxy, not the employees. A reverse proxy is set up by the website's owner; visitors see the proxy, not the servers.
A short way to remember it: a forward proxy hides the clients from the servers, and a reverse proxy hides the servers from the clients. A VPN is closer to a forward proxy, since it works for you, the client.
An API gateway is a reverse proxy that also knows who is calling. It checks API keys or tokens, applies quotas per customer, and sets rules per route. A CDN such as Cloudflare or CloudFront is a reverse proxy run for you in hundreds of cities. Cached answers come from a server near each visitor. Cloudflare's main product is, in fact, a large reverse proxy that you point your DNS at.
A reverse proxy adds one more thing that can break, and every request now depends on it. The common failure modes are worth knowing before you add one.
When not to use one: a single small app on a platform that already handles HTTPS gains little from a proxy you run yourself. Many hosts, including the one this site runs on, already put a managed reverse proxy in front of your code. Add your own when you have several copies or several services behind one name. Also add one when you need caching, routing or limits that your platform does not give you.
This page covers what a reverse proxy is and what one looks like from the inside. The Reverse Proxy lesson in my course goes further. It covers the full forwarded-header table and its trust rules, health checks, and telling 502 from 504. It also covers the buffering default that breaks streaming, and how to run proxies so one of them is never the outage.
nginx
The most common self-hosted reverse proxy. The proxy_pass, upstream and proxy_cache directives used on this page are all core nginx.
Cloudflare
A reverse proxy run for you at the edge. You point your DNS at it, and it terminates TLS, caches and filters before your origin sees a request.
HAProxy
A load balancer and reverse proxy known for layer 4 and layer 7 balancing with detailed health checks.
Envoy
A reverse proxy configured over an API, used as the data plane in most service meshes and many API gateways.
Caddy and Traefik
Caddy gets and renews HTTPS certificates on its own; Traefik discovers backends from container labels as you deploy.
AWS Application Load Balancer
A managed layer 7 load balancer: in practice a reverse proxy that AWS runs, routing by path and host.
It receives every request for your servers, so shared jobs happen in one place. It holds the HTTPS certificate, spreads load, caches answers and routes paths to different services. It also limits abusive clients and hides the servers from the internet.
A forward proxy works for the clients. An office or school sends its users' traffic through it, and websites see the proxy instead of the users. A reverse proxy works for the servers. A website puts it in front of its servers, and visitors see the proxy instead.
nginx is a web server, but one of its main jobs is to sit in front of other servers. It forwards requests to them with proxy_pass. Used that way it acts on the servers' behalf, which is what reverse means here. It can also serve files itself and balance load across backends.
Often, but not always. A layer 7 load balancer, which reads HTTP requests, is a reverse proxy that spreads traffic across servers. A layer 4 load balancer only moves TCP connections and does not read the request, so it cannot cache or route by path. And a reverse proxy with one backend does no balancing at all.
Yes. When you point your domain at Cloudflare, visitors connect to Cloudflare's servers. They terminate TLS, cache and filter attacks, then forward the rest to your own server, the origin.
Yes, it is software facing the internet, so it needs patches like anything else. It also concentrates risk: a bad config or expired certificate breaks every service behind it. Common mistakes are trusting a client-supplied X-Forwarded-For and leaking backend details in error pages. Keep it updated, run two, and overwrite forwarding headers at the edge.
It adds a network hop, usually around a millisecond on the same network. It is one more system to configure and monitor, and a single point of failure if you run only one. Apps must be told to trust forwarded headers, and buffering can break streamed responses unless you turn it off for those routes.
Checked against these on .
Server-Side Caching
Caching the finished response removes all the work, and one personalised element removes all the benefit
Varnish Cache
The hit rate was 0.0 percent as the framework ships and 99.0 percent with one response header removed. At 80 percent of visitors cookied, 15,913 of 20,000 requests skipped the cache
Path-Based Routing for Microservices: How a Proxy Picks a Service by URL Path
Path-based routing for microservices request routing, tested on real nginx, Envoy and HAProxy: nginx location order, ALB path rules, Ingress, path vs host.
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.
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.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
API Gateway
A single entry point for all client requests that routes them to the appropriate microservice. Handles auth, rate limiting, and request transformation.
SSL Termination
Decrypting TLS-encrypted traffic at a load balancer or reverse proxy so backend servers receive plain HTTP. Offloads CPU-intensive crypto work and simplifies certificate management.
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.
This page explains the idea. The "Reverse Proxy" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Reverse Proxy lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Reverse Proxy in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
