What's the difference between a reverse proxy and a load balancer?

Every load balancer is technically a reverse proxy — both accept connections on behalf of backends. The distinction is operational: a load balancer emphasizes distributing traffic (often at L4 for raw throughput); a reverse proxy emphasizes application-layer features like TLS termination, caching, URL rewrites, and auth (always at L7). Modern tools like NGINX, HAProxy, and Envoy do both.

Is NGINX a reverse proxy or a load balancer?

Both. NGINX is a reverse proxy that also functions as a load balancer via upstream blocks with algorithms like least_conn, ip_hash, and weighted round-robin. You configure both functions in the same NGINX file. The same applies to HAProxy, Traefik, Envoy, and Caddy.

When should I use L4 vs L7 load balancing?

Use L4 for non-HTTP protocols (MySQL, gRPC over raw TCP, MQTT, custom binary), maximum throughput (1M+ pps), TLS pass-through, and lowest latency. Use L7 for HTTP/gRPC services, path or host-based routing, TLS termination, caching, A/B testing, and WAF integration. Most modern web stacks use L7.

What does an Ingress do in Kubernetes?

An Ingress is an L7 reverse proxy / load balancer running inside your Kubernetes cluster. It terminates TLS, routes by host and path, and forwards to Service backends. The actual implementation is a pod running NGINX, Traefik, or Envoy. The Gateway API (2024+) is the successor to Ingress with a more expressive spec.

Is HAProxy faster than NGINX?

HAProxy is typically faster than NGINX in L4 (TCP) mode — its event-driven core was built specifically for that. In L7 (HTTP) mode the two are close, with HAProxy slightly edging out NGINX on raw RPS but NGINX winning on broader features (caching, static files, plugin ecosystem). Both can comfortably handle 50k+ HTTPS RPS per core.

Do I need a load balancer if I have a reverse proxy?

A reverse proxy with multiple backends configured *is* a load balancer. You don't need both products if one tool covers it. The questions to ask: is the reverse proxy's load-balancing algorithm enough, can it handle the throughput you need, and does it offer the health-check and session-affinity features your stack requires.

What's the difference between an AWS ALB and NLB?

ALB (Application Load Balancer) is L7 — it parses HTTP, supports path and host routing, terminates TLS, integrates with WAF and Cognito. NLB (Network Load Balancer) is L4 — it forwards TCP and UDP at line rate, preserves source IP, and handles millions of packets per second. ALB for web apps, NLB for non-HTTP services or extreme throughput.

Is Envoy a reverse proxy?

Yes. Envoy is a modern L7 reverse proxy and load balancer originally built at Lyft, now the data plane for Istio and many cloud-native systems. It does dynamic configuration via xDS, gRPC-native routing, advanced observability, and runs as both edge proxy and per-pod sidecar in service meshes. Compared to NGINX it's more programmatic, with config delivered over APIs.

Reverse Proxy vs Load Balancer (2026)

Quick verdict: Every load balancer is technically a reverse proxy — both accept inbound connections on behalf of one or more backends. The distinction in 2026 is operational, not architectural. A load balancer emphasizes distributing traffic across many backends (and usually operates at L4 for raw throughput). A reverse proxy emphasizes application-layer features: TLS termination, caching, URL rewrites, auth, observability (and usually operates at L7). Tools like NGINX, HAProxy, Envoy, and Traefik happily wear both hats. The labels matter only when you're picking a tool: do you need raw packet routing across 100k connections per second, or do you need to manipulate HTTP requests?

The Two Definitions

	Reverse Proxy	Load Balancer
Primary purpose	Front backends with app-layer features	Distribute requests across backends
OSI layer	L7 (HTTP)	L4 (TCP) or L7 (HTTP)
Number of backends	One or many	Many by definition
Awareness	HTTP semantics (headers, paths, methods)	L4: just sockets. L7: same as reverse proxy.
Typical features	TLS, caching, compression, URL rewrite, auth, A/B routing	Health checks, weighted routing, session affinity, connection pooling
Throughput per box	10k–100k RPS	100k–1M+ packets/sec (L4)
Examples	NGINX, Traefik, Caddy, Cloudflare, Envoy	HAProxy (L4), AWS NLB, IPVS, kube-proxy, F5

L4 vs L7: Where the Real Distinction Lives

L4 Load Balancer

An L4 LB sees TCP packets. It picks a backend (based on source IP + port hash, round-robin, least-connections) and forwards packets there. It doesn't parse the application protocol. AWS Network Load Balancer (NLB), Azure Standard LB, IPVS in Linux kernel, and HAProxy in TCP mode all operate L4.

Pros: Insanely fast (millions of packets/sec), protocol-agnostic (TCP, UDP, TLS pass-through), low latency.
Cons: Can't make decisions based on HTTP path / header / cookie. No TLS termination (it just forwards bytes). No caching.

L7 Reverse Proxy / Load Balancer

An L7 proxy terminates the inbound TCP, parses the HTTP request, and makes routing decisions based on path, host, headers, method, cookies, body. It can rewrite URLs, add headers, cache responses, terminate TLS, do authn/authz. NGINX, Traefik, Envoy, ALB, Cloudflare all operate L7.

Pros: Full app-layer routing, TLS termination, caching, compression, header manipulation, WAF integration.
Cons: Slower than L4 (10x typically), uses more CPU, only handles application protocols it understands (HTTP, gRPC, WebSocket).

The Overlap

Modern L7 proxies are load balancers. NGINX has upstream blocks with multiple servers and load-balancing algorithms (least_conn, ip_hash, random). HAProxy in HTTP mode does the same. Envoy was built for service mesh and is a load balancer by default. The distinction "reverse proxy or load balancer" is a false choice for these tools — pick the right tool, configure both functions.

When You Want L4

Non-HTTP protocols. MySQL, PostgreSQL, gRPC over raw TCP, custom binary protocols, MQTT. L7 proxies can't parse these (well).
Maximum throughput. 1M+ packets/sec on commodity hardware.
TLS pass-through. Backend handles TLS; LB just forwards encrypted bytes.
Lowest latency. Game servers, high-frequency trading, low-latency APIs.

Tooling: AWS NLB, GCP TCP LB, Azure Standard LB, IPVS, HAProxy TCP mode, kube-proxy (when not using IPVS mode).

When You Want L7

HTTP / gRPC services. Microservices, web apps, APIs.
Path-based routing. /api goes to one service, /static to another.
Host-based routing. Multi-tenant apps, multiple domains on one IP.
TLS termination. Centralize SSL certs at the edge.
Caching, compression, header manipulation.
A/B testing, canary releases, blue/green.
WAF, rate limiting, JWT auth.

Tooling: NGINX, Envoy, Traefik, Caddy, AWS ALB, GCP HTTPS LB, Azure App Gateway, Cloudflare.

Tools Side-by-Side (2026)

Tool	L4	L7	Best at
NGINX (+ Plus)	Yes	Yes	Mature L7, caching, static files, vast plugin ecosystem
HAProxy	Yes	Yes	Highest-throughput L4, ACL-based L7
Envoy	Limited	Yes	Service mesh, observability, gRPC, xDS dynamic config
Traefik	Yes	Yes	Container-native, auto-discovery, Let's Encrypt out of the box
Caddy	Limited	Yes	Zero-config HTTPS, simple config, small ops surface
AWS NLB	Yes	No	L4 at AWS scale
AWS ALB	No	Yes	L7 at AWS scale, integrates with Cognito, WAF
kube-proxy / IPVS	Yes	No	Kubernetes Service routing
Cloudflare	Spectrum	Yes	Edge L7 with DDoS, WAF, cache; L4 via Spectrum

In Kubernetes

Both labels apply in different layers of the stack:

Service (ClusterIP) — kube-proxy / IPVS does L4 load balancing across Pod IPs.
Service (LoadBalancer) — provisions a cloud L4 LB (NLB equivalent).
Ingress — an L7 reverse proxy (typically NGINX, Traefik, or Envoy) running inside the cluster, terminating TLS and routing by host/path.
Gateway API — the 2024+ successor to Ingress, also L7, more expressive.
Service Mesh (Istio, Linkerd) — L7 proxies (Envoy sidecars) for every Pod, doing mTLS, observability, retries.

Load-Balancing Algorithms

Algorithm	How it picks a backend	When to use
Round Robin	Each request to the next backend in sequence	Stateless, identical backends
Least Connections	Backend with fewest active connections	Long-lived connections (WebSocket, DB)
IP Hash	Hash of client IP picks backend	Session affinity without cookies
Consistent Hash	Stable mapping under backend changes	Caches, sharded services
Weighted Round Robin	Backends with higher weight get more	Heterogeneous backends
Least Response Time	Backend with lowest p50	Latency-sensitive APIs
Random	Pseudo-random pick	Often enough, simpler than LC

Health Checks

Both types do health checks, but L7 health checks are smarter:

L4: Open a TCP socket; if it accepts, the backend is "up". Cheap, fast, but a stuck app accepting connections without responding looks "healthy".
L7: Make a real HTTP request; check the response status, body, or a specific endpoint (/healthz). Catches app-level failures (stuck app, OOM, deadlock).