What Is a Reverse Proxy, and How Is It Different From a Load Balancer?

"Reverse proxy" and "load balancer" get used almost interchangeably in casual conversation, and in practice a single piece of software (Nginx, HAProxy, Envoy) often does both jobs at once — which is exactly why the distinction gets blurry. But they solve different problems, and understanding which one you actually need (or that you need both, layered together) matters once you're designing anything beyond a single server handling all your traffic directly.

What a reverse proxy actually does

A reverse proxy sits in front of one or more backend servers and intercepts client requests on their behalf, forwarding each request to an appropriate backend and returning that backend's response back to the client — from the client's point of view, they're talking to the proxy itself, with no visibility into what's actually serving the request behind it. This is the mirror image of a forward proxy, which sits in front of clients and makes requests to the internet on their behalf (a corporate network's outbound proxy, for instance) — a reverse proxy protects and represents servers, while a forward proxy protects and represents clients. The name genuinely reflects which direction it's facing relative to the request.

Why put a reverse proxy in front of your servers at all

• Hiding backend topology — clients only ever see the proxy's address, never the actual internal server addresses, ports, or architecture, which is a real security and flexibility benefit since backend servers can be added, removed, or moved without clients noticing anything changed.
• TLS termination — the reverse proxy can handle HTTPS/TLS encryption and decryption once, at the edge, so backend servers only need to speak plain HTTP internally, simplifying certificate management to one place instead of every server.
• Centralised caching — a reverse proxy can cache responses for frequently requested content, serving repeat requests directly without hitting the backend at all, reducing load on the actual application servers.
• Compression and request/response rewriting — handling gzip/br compression, adding security headers, or rewriting URLs centrally rather than configuring it identically on every backend server.
• Routing by path or domain — a single entry point can route `/api/*` to one backend service and `/images/*` to another, letting you run multiple distinct services behind what looks like one unified address to the outside world.

What a load balancer actually does

A load balancer's specific job is distributing incoming traffic across multiple servers that are all capable of handling the same request, so no single server gets overwhelmed while others sit idle — the core problem it solves is horizontal scaling: instead of one increasingly large server handling everything, many smaller servers share the load, and the load balancer decides which one handles each incoming request. It typically also performs health checks, continuously verifying which backend servers are actually up and responsive, and automatically routing traffic away from any server that's failed a health check — turning a single dead server into a transparent, uninterrupted failover instead of a visible outage. Our own load balancer explainer covers the specific distribution algorithms (round robin, least connections, and others) in more depth.

So where's the actual overlap?

A reverse proxy, by definition, can forward a request to any of several backend servers — which means the moment it's choosing between more than one backend for the same type of request, it's *also* doing load balancing, whether or not that was the primary reason it was deployed. This is precisely why software like Nginx and HAProxy is described as both a reverse proxy and a load balancer: the reverse-proxy layer (intercepting and forwarding client requests, terminating TLS, hiding backend topology) and the load-balancing layer (choosing which specific backend instance handles this particular request, health-checking backends) are complementary functions the same piece of software commonly performs together, not two competing categories of tool you'd choose between.

A concrete example: a typical web app's request path

1. A client's browser resolves your domain via DNS and connects to a public-facing reverse proxy (say, Nginx or a managed cloud load balancer).
2. The proxy terminates TLS, decrypting the HTTPS connection so the rest of the infrastructure can speak plain HTTP internally.
3. Based on the request path, the proxy routes `/api/*` traffic to your application server pool and static asset requests to a CDN or static file server.
4. For the application server pool, the proxy (now acting as a load balancer) picks one of several running instances — using round robin, least connections, or another algorithm — and forwards the request there.
5. The chosen backend server processes the request and returns a response, which the proxy relays back to the client, potentially caching it along the way if it's cacheable content.

Reverse proxy vs CDN — another commonly confused pair

A CDN is, in a sense, a globally distributed reverse proxy — it sits between clients and your origin server, caching and serving content from edge locations physically closer to each client, which is exactly the reverse-proxy pattern of intercepting client requests and deciding how to fulfil them, applied at a global geographic scale. The distinction that matters in practice is scope and purpose: a CDN's edge network is optimised specifically for caching and serving static (and increasingly dynamic) content from locations near the end user to reduce latency, while a reverse proxy in front of your own infrastructure is typically solving a narrower, more application-specific set of problems — routing, TLS termination, and load distribution across your own backend fleet, often working alongside a CDN rather than replacing it.

Common reverse proxy software you'll actually run into

• Nginx — extremely widely used both as a reverse proxy and a general-purpose web server, known for handling large numbers of concurrent connections efficiently.
• HAProxy — historically strong specifically as a load balancer and reverse proxy for TCP and HTTP traffic, common in high-availability setups.
• Envoy — a modern proxy built with microservices and service-mesh architectures in mind, commonly used inside Kubernetes clusters for both edge and internal service-to-service traffic.
• Traefik — designed to automatically discover backend services in dynamic, container-based environments (Docker, Kubernetes) and reconfigure routing without manual restarts.
• Cloud-managed load balancers (AWS ALB/NLB, Google Cloud Load Balancing, Azure Load Balancer) — the same reverse-proxy-plus-load-balancing role, provided as a managed service rather than software you run and patch yourself.

Do you need one if you're just running a single server?

Even with a single backend server, a reverse proxy in front of it is a common and reasonable setup — you still get TLS termination in one place, the ability to add caching or rate limiting later without touching the application itself, and critically, the option to add a second backend server later purely by changing the proxy's configuration rather than re-architecting anything client-facing. This is a big part of why reverse proxies are so ubiquitous even for modest deployments: they're cheap to add early and make scaling out later a configuration change rather than a redesign.

Common misconceptions

• Assuming a reverse proxy and a load balancer are two different products you'd pick between — in most real deployments, one piece of software does both jobs together.
• Assuming load balancing requires a dedicated hardware appliance — modern software load balancers (and managed cloud offerings) handle the vast majority of real-world traffic today.
• Confusing a reverse proxy with a forward proxy because both have "proxy" in the name — they face opposite directions and solve different problems (protecting servers vs protecting clients).
• Thinking a CDN replaces the need for a reverse proxy in front of your own origin servers — a CDN typically caches in front of your origin, but your origin's own backend fleet often still needs its own reverse proxy/load balancer layer behind the CDN.

Layer 4 vs Layer 7 — the distinction that actually matters for load balancing

Load balancers (and reverse proxies acting as one) generally operate at one of two levels of the network stack, and which one matters a lot for what routing decisions are actually possible. A Layer 4 load balancer works at the transport layer — it sees IP addresses and TCP/UDP ports, and makes routing decisions based purely on that connection-level information, without inspecting the actual HTTP request inside it. It's fast and protocol-agnostic (it'll happily balance any TCP traffic, not just HTTP), but it can't route based on a URL path, a header, or a cookie, because it never looks that deep. A Layer 7 load balancer, by contrast, operates at the application layer — it actually parses the HTTP request, which is exactly what makes path-based routing (`/api/*` to one pool, `/images/*` to another), header-based routing, and cookie-based session affinity possible. Nginx, HAProxy and most reverse proxies discussed here typically operate at Layer 7 when handling HTTP traffic, which is why they can make the kind of content-aware routing decisions a pure Layer 4 balancer structurally can't.

Sticky sessions — when load balancing needs to remember the client

Distributing every request to a random backend works cleanly for stateless applications, but plenty of real applications store some session state in server memory (a shopping cart, a login session not backed by a shared store) — and for those, sending a client's *second* request to a different server than their first can mean that server has no idea who they are. Sticky sessions (session affinity) solve this by having the load balancer consistently route a given client's requests to the same backend server, typically using a cookie the proxy sets or client IP-based hashing. This is a reasonable short-term fix, but it's worth recognising as a workaround rather than a design goal — an application that keeps session state in a shared store (Redis, a database) instead of server memory doesn't need sticky sessions at all, and scales more cleanly as a result, since any backend can serve any request without needing to "remember" the client itself.

Reverse proxy vs API gateway

An API gateway is best understood as a reverse proxy with a specific job description layered on top: in addition to routing and load balancing, it typically also handles authentication/authorization for API requests, rate limiting per client or API key, request/response transformation between an external API contract and internal service formats, and often API analytics and billing metering. Every API gateway is, structurally, a reverse proxy — but not every reverse proxy is trying to be an API gateway, since a basic reverse proxy in front of a single web application has no need for API-key-based auth or per-client rate limiting. The distinction is mostly about which additional, application-aware features are layered onto the same underlying reverse-proxy pattern, particularly relevant in a microservices architecture where an API gateway is the single, consistent entry point in front of many internal services.

Security benefits a reverse proxy provides almost for free

Beyond routing and performance, putting a reverse proxy in front of your backend servers closes off a meaningful attack surface simply by design — backend servers are never directly reachable from the public internet, which means a vulnerability in a specific backend's network stack or an exposed internal port isn't independently exploitable from outside. Many reverse proxies also support Web Application Firewall (WAF) rules, filtering known attack patterns (SQL injection attempts, malformed requests) before they ever reach the application, and can absorb a meaningful amount of basic denial-of-service traffic at the edge, in front of application servers that would otherwise have to handle that load themselves. None of this makes backend-level security unnecessary, but it does mean the reverse proxy layer is a genuinely useful, centralised place to enforce baseline protections once, rather than duplicating them across every backend service individually.