A reverse proxy is the front door of a website. Clients talk to it, and it forwards their requests to the servers behind it. A load balancer spreads requests across several servers. The two overlap so much that one tool often does both. The HTTP standard, RFC 9110, calls a reverse proxy a gateway, "an intermediary that acts as an origin server for the outbound connection". Among its uses, the standard lists "load balancing of HTTP services across multiple machines".
We built a small one to show both jobs at work, and read the headers of 100 top sites to see who answers for them.
What does a reverse proxy do?
It stands in for the site. The client sees one address, the proxy's, and never the servers behind it. The proxy reads each request, decides where it goes, and passes the answer back. RFC 9110 names three reasons to run one: to wrap older services, to speed things up with "accelerator" caching, and to split or balance traffic.
The server behind it sees the connection come from the proxy, not from the client. So the proxy adds a header with the client's address. RFC 7239 standardised one, Forwarded, whose "for" parameter is used "to disclose information about the client that initiated the request". Before it, the standard notes, proxies used "non-standard header fields such as X-Forwarded-For". Our demo below uses that one. A forward proxy works the other way round, for the client rather than for the site, as we explain in forward vs reverse proxy.
What does a load balancer do?
It spreads the load. AWS describes its own as a service that "automatically distributes your incoming traffic across multiple targets". It also "monitors the health of its registered targets, and routes traffic only to the healthy targets".
nginx, which can do the job too, offers three ways to pick the next server:
- Round robin: each request goes to the next server in turn.
- Least connected: the request goes to the server with the fewest active connections.
- ip-hash: "the client's IP address is used as a hashing key" to pick the server, so the same client keeps reaching the same one.
When a server fails, nginx "will mark this server as failed, and will try to avoid selecting this server for subsequent inbound requests for a while".
Where do they differ?
The real line is the network layer. AWS runs both kinds. Its Application Load Balancer "functions at the application layer, the seventh layer" of the OSI model, and reads HTTP. Its Network Load Balancer "functions at the fourth layer", and sees only addresses and ports.
| Reverse proxy | Load balancer | |
|---|---|---|
| Main job | Stands in for the site | Spreads requests over servers |
| Servers behind it | One or many | Several |
| Layer | 7, it reads HTTP | 7, or 4 without reading HTTP |
| Adds X-Forwarded-For | Yes | Only at layer 7 |
| Examples | nginx, HAProxy | nginx, HAProxy, AWS ALB (7), AWS NLB (4) |
So a load balancer at layer 7 is a reverse proxy that balances. HAProxy describes itself in exactly those terms: "a free, very fast and reliable reverse-proxy offering high availability, load balancing, and proxying for TCP and HTTP-based applications". A layer-4 balancer is the one case that is not a reverse proxy.
Our demo: one program, both jobs
We wrote a reverse proxy that balances load, in Python, with three small app servers behind it, all on one machine. A client sent requests from its own address, 127.0.0.2:
- Load balancing: the first six requests went to app-1, app-2, app-3 and around again.
- Health: we stopped app-2. The next six requests went to app-1 and app-3 only, and none failed.
- Reverse proxy: every app server saw the connection come from 127.0.0.1, the proxy. The client's own address arrived only in X-Forwarded-For.
- ip-hash: we switched methods and sent requests from three addresses in turn. Each address reached the same app server both times it asked.
Who answers for the top 100 sites?
We read the headers of the first 100 sites in the Tranco ranking that answered with a page on 11 October 2026. At least 45 of them answered through a known edge network, which stands in front of the site's own servers. Cloudflare answered for 15, Amazon CloudFront for 9, Akamai and Fastly for 8 each, and Google's front end for 5.
The Server header told the same story. It often named a proxy, not the application: nginx on 14 sites, cloudflare on 13, envoy on 4. 22 answers carried a Via header, which shows "the presence of intermediate protocols and recipients" between the server and the client, in RFC 9110's words.
What does this mean behind a proxy?
When you use a proxy yourself, a site's reverse proxy sees your proxy's exit, and passes that address on to its own servers. Two things follow.
First, errors can come from the front door rather than the site. A Cloudflare 520 is one of them, as we show in Cloudflare error 520.
Second, stickiness by address does not survive rotation. With ip-hash, the address picks the server. If your exit changes on every request, each request can land on another server, and a session that lives on one server can get lost. A sticky session keeps one exit for the length of a login, as we explain in sticky vs rotating proxy sessions. Our residential proxies offer both modes.
What this page could not check
- The demo is our own small Python program on one machine, not nginx, HAProxy or a cloud balancer. It shows the ideas, not their speed.
- The header analysis reads what sites send. Edge networks can hide or rename their headers, so 45 is a lower bound.
- 100 sites from one ranking, read once from one server in the United States.
- Our list of markers covers five large edge networks. Sites behind smaller ones, or behind their own proxies, count as having none.
- Tools change with new versions. We will run the demo and the analysis again by 11 January 2027.
Sources
- RFC 9110, HTTP Semantics, the gateway definition, IETF, June 2022: rfc-editor.org.
- RFC 7239, Forwarded HTTP Extension, IETF, June 2014: rfc-editor.org.
- nginx, Using nginx as HTTP load balancer, read 11 October 2026: nginx.org.
- HAProxy, home page, read 11 October 2026: haproxy.org.
- AWS, What is Elastic Load Balancing, read 11 October 2026: docs.aws.amazon.com.
- AWS, Network Load Balancer overview, read 11 October 2026: docs.aws.amazon.com.
- AWS, Application Load Balancer overview, read 11 October 2026: docs.aws.amazon.com.
- Tranco, list 8PXYV, created 10 October 2026: tranco-list.eu.
- Our own demo, lb_demo.py, and our analysis of the headers saved by our cookie survey, on our server, 11 October 2026.
