Proxy vs Reverse Proxy vs Load Balancer — What's Actually Different

Proxy vs Reverse Proxy vs Load Balancer: What's Actually Different#

These three terms get mixed up constantly — partly because the same software (Nginx, HAProxy, Envoy) plays all three roles depending on how you configure it. The differences are real and worth knowing because they map to different decisions you make when designing a system.

This post is a practical breakdown: what each does, where each sits in the request path, what they're each good and bad at, and the cases where the distinction stops mattering because one tool is doing all three at once.

The mental model in one sentence each#

• Forward proxy sits between clients and the internet. Clients know about it; the destination doesn't.
• Reverse proxy sits between the internet and your backend servers. The destination (browser/client) thinks the reverse proxy is the server.
• Load balancer distributes incoming traffic across multiple identical backends. It's a specific job, not a specific position in the stack.

The first two are about who knows about whom. The third is about how many backends share the work.

Forward proxy#

A forward proxy is something a client deliberately routes its traffic through. The client says "send my request to the proxy, and have the proxy forward it." The proxy talks to the destination on the client's behalf; the destination sees the proxy's IP, not the client's.

Why anyone runs one:

• Corporate network egress control. Block specific sites, filter content, log all outbound traffic for compliance. Common in enterprises.
• Caching. Multiple clients hitting the same external resources (npm registry, docker hub, OS package mirrors) — proxy caches once, serves many.
• Anonymity / privacy. The destination only sees the proxy's IP. The basis for VPNs and Tor.
• Geographic routing. Make outbound requests appear from a specific country.

Common implementations: Squid (the classic), corporate solutions like Zscaler, internal HTTP proxies built on Nginx in proxy mode.

Advantages:

• One central choke point for outbound traffic — easy to audit and control.
• Caching benefits compound across many clients.
• Clients can be simple (just set HTTPS_PROXY=...).

Disadvantages:

• Single point of failure for client internet access (unless you scale it out).
• Performance bottleneck if undersized.
• Adds latency on every outbound request.
• HTTPS inspection requires certificate trust on every client (deep packet inspection on TLS).

You usually don't need to think about forward proxies unless you're working in an enterprise environment that has one, or you're building a system that does a lot of outbound calls and wants to cache or audit them.

Reverse proxy#

A reverse proxy sits in front of your servers. From the outside, the reverse proxy is the server — browsers connect to it, give it their requests, and receive responses. Behind the scenes, the proxy forwards the request to one of your backend servers and returns the response.

Why everyone runs one:

• TLS termination. Reverse proxy handles HTTPS; backends speak plain HTTP. Centralizes cert management.
• Hide your topology. Backend servers' IPs aren't exposed to the internet. Smaller attack surface.
• Header manipulation, request rewriting, redirects. Centralized point to do these without touching backend code.
• Caching. Cache responses at the edge for static or semi-dynamic content.
• Compression. Gzip/Brotli at the proxy layer.
• WAF. Web Application Firewall rules at the front door.
• Routing. "Requests to /api → backend A; requests to /static → backend B."

Common implementations: Nginx, HAProxy, Envoy, Caddy, Traefik. Cloud-managed versions: AWS ALB, CloudFront, Cloudflare.

Advantages:

• One place to handle TLS, compression, headers, caching, security rules.
• Backends can be simple HTTP servers — they don't deal with the public internet.
• Easy to add cross-cutting features (rate limiting, auth gates) without touching each service.
• Adds a security layer between the internet and your backends.

Disadvantages:

• Another moving piece to monitor and scale.
• Misconfiguration can break every request (single point of failure if not HA).
• Adds a hop of latency (small but real).
• Debugging gets harder — is the issue at the proxy or the backend?

If you're running anything on the public internet, you're almost certainly using a reverse proxy whether you realize it or not. CloudFront in front of a Vercel app? Reverse proxy. Nginx in front of your Node app? Reverse proxy.

Load balancer#

A load balancer distributes incoming traffic across multiple backend servers. The "balance" part: it tries to give each backend a fair share of work.

Two flavors:

• L4 (Layer 4 / TCP) load balancer. Operates on TCP connections. Doesn't look inside the requests. Fast, simple, protocol-agnostic. AWS NLB is L4.
• L7 (Layer 7 / HTTP) load balancer. Inspects HTTP. Can route based on path, headers, cookies. Can do sticky sessions ("this user → same backend"). AWS ALB is L7.

Why you run one:

• Horizontal scale. One backend can't handle the load; spread across many.
• High availability. If one backend dies, the LB routes around it.
• Rolling deploys. Take backends out of rotation one at a time, deploy, return to rotation.
• A/B testing or canary deploys. Send X% of traffic to the new version.

Common implementations: cloud LBs (AWS ALB/NLB, GCP Load Balancer), self-hosted (HAProxy, Nginx, Envoy), Kubernetes Services (which are an L4 LB internally).

Advantages:

• Real horizontal scalability — add backends to handle more load.
• HA: backend failures become invisible to clients.
• Decouples deploy from availability.

Disadvantages:

• Yet another moving piece, must itself be HA.
• Stateful behavior (sessions, sticky routing) adds complexity.
• L7 inspection costs CPU vs L4 pass-through.

Where they overlap#

This is where the terminology gets confusing: a reverse proxy that has multiple backends configured is also a load balancer. The same Nginx config block can do both:

upstream app_backends {
    server app1.internal:3000;
    server app2.internal:3000;
    server app3.internal:3000;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    location / {
        proxy_pass http://app_backends;
    }
}

That's a reverse proxy (terminating TLS, forwarding to backends) AND a load balancer (distributing across three backends). Same tool, same config, two roles.

In practice, the distinction matters most when:

• You have one backend → it's a reverse proxy, not really a load balancer.
• You have many backends, but no public-facing role → it's a load balancer between internal services.
• You have many backends, public-facing → it's both, and arguing about the name is a waste of time.

A quick comparison table#

How to pick#

A rough decision flow:

• You need to control or audit outbound traffic from many machines? Forward proxy.
• You're putting a service on the public internet and need TLS, security, or routing? Reverse proxy.
• You have multiple identical backends and need to distribute traffic? Load balancer.
• All three? Multiple backends, public-facing, with security/TLS needs? One tool (Nginx, Envoy, or a cloud ALB) does all of it.

For most production teams, the answer is: deploy a cloud-managed L7 load balancer (ALB on AWS, similar elsewhere) which acts as both the reverse proxy AND the load balancer. The forward proxy use case is separate and usually only matters in enterprise contexts.

Common confusions#

A few patterns that trip people up:

• "My Nginx is a load balancer." If it points at one backend, it's a reverse proxy. If it points at several, it's both. The name "load balancer" implies multiple backends.
• "I'm using a proxy." Always ask: forward or reverse? They're completely different things despite the shared word.
• "My CDN is a reverse proxy." Yes. CloudFront, Cloudflare, Fastly — all reverse proxies with caching and a global edge network.
• "My service mesh sidecar is a proxy." Yes — usually a reverse proxy from the perspective of the local service, and a forward proxy from the perspective of outbound calls. Modern sidecars (Envoy in Istio/Linkerd) blur the line.

What to read next#

• Cloud networking fundamentals: VPCs, subnets, routing — where these pieces fit in cloud network topology
• Service mesh implementation: Istio vs Linkerd — when every service gets its own little reverse proxy
• Kubernetes networking deep dive — how K8s Services and Ingresses map onto these concepts

Once these three terms stop blurring together, a lot of system designs read more clearly. The same tools play different roles in different positions — Nginx in front of a single backend is a reverse proxy; the same Nginx with multiple backends configured is a load balancer; an Nginx config that clients explicitly route through is a forward proxy. The job, not the binary, is what determines which name applies.