Comparisons & judgement · 7 chapters · ~22 min read

Reverse Proxy · Engineering Insights

The trade-offs and comparisons that decide how you actually deploy a reverse proxy: direct access versus a proxy, proxy versus load balancer, proxy versus API gateway, where to cache, where to terminate SSL, the mistakes teams commonly make once, and the real-world architectures these questions point toward.

Mangesh MandlikLast updated: 5 November 2026

01 · The core trade

Direct Access vs Reverse Proxy

Skipping the proxy keeps the diagram simple, but once edge concerns multiply it pushes the same operational work into every app server.

Swipe to pan

Direct access hands every cross-cutting concern to each app server.

Direct access has one clear advantage: one fewer hop and one fewer component to operate. For a small internal app or a single server, that may be entirely reasonable. As soon as you need shared TLS policy, static asset delivery, multiple public routes, caching, or an internet-facing security layer, those concerns either get duplicated across app servers or embedded awkwardly into the application itself.

Direct access

Fewer components, but each server terminates its own SSL, serves its own static, defends itself, and hardcodes its own routing. Doesn't scale in concerns or servers.

Reverse proxy

One more hop, but SSL, static, routing, caching, and security move to a single shared edge layer. Backends get simpler as the system grows.

02 · Overlap without equivalence

Reverse Proxy vs Load Balancer

The interesting design question is not whether the labels overlap — they do. It is when one Nginx tier is enough and when a separate load-balancing layer is worth adding.

Swipe to pan

Sometimes one reverse proxy is enough; at larger scale a dedicated load balancer often sits in front and lets the proxy tier focus on HTTP features.

If your main need is "one public HTTP(S) entry point" with TLS termination, path routing, caching, compression, and maybe some simple balancing across a few origins, a reverse proxy alone can be the right first step. It keeps the stack small while still solving the application-facing edge problems.

A dedicated load balancer earns its place when connection distribution, health-checked backend pools, L4 options, or very high throughput become important enough to separate from HTTP feature work. Then the architecture often becomes: load balancer chooses which proxy node gets the connection; reverse proxy decides how to handle the HTTP request after it arrives. For the full load-balancing mechanics, see Load Balancer Fundamentals.

03 · Same engine, different job

Reverse Proxy vs API Gateway

An API gateway is usually a reverse-proxy-based layer with extra API policy, not a totally separate species of network box.

A reverse proxy is a general web edge component: it terminates TLS, routes by host or path, caches safe responses, compresses content, serves static assets, and hides origins behind one public entry point. It may front one backend or many; the key is that its centre of gravity is HTTP transport and edge behaviour.

An API gateway adds API-specific responsibilities on top of that foundation: authn/authz, per-consumer rate limits, request transformation, aggregation, versioning, developer-facing API products, and analytics. In many platforms the gateway is literally implemented with reverse-proxy technology underneath. Choose the gateway when API policy is the hard part; choose the simpler reverse proxy when transport concerns are the hard part. See API Gateway Fundamentals for the full API-facing model.

Reverse proxy

General-purpose HTTP(S) front door for applications and services. Strong at TLS termination, routing, caching, compression, static delivery, and origin hiding.

API gateway

A reverse-proxy-based API layer that adds identity, policy, transformations, quotas, analytics, and lifecycle concerns for many client-facing APIs.

04 · Where to cache

Cache at Proxy vs Application

Caching at the proxy and caching inside the app solve different problems — most systems want both.

Swipe to pan

Proxy cache answers before the backend is ever touched; app cache speeds up work the backend still has to do.

A proxy cache stores whole HTTP responses and serves hits without ever waking the backend — maximum relief, but it can only cache what's safe to share and shaped like an HTTP response. An application cache (in-memory objects, Redis) caches computed fragments, query results, and per-user data the proxy can't safely store, but the request still reaches and runs through the app.

Use the proxy cache for shared, cacheable pages and assets to shield the backend entirely; use the app cache for fine-grained, per-user, or partial results. They stack: a proxy-cache miss can still hit a warm app cache.

05 · Where to terminate TLS

SSL at Proxy vs Application

Terminating TLS at the proxy is the default because it centralises certificates and unlocks HTTP-aware edge features; end-to-end encryption changes what happens on the internal hop, not that basic benefit.

Swipe to pan

Terminate at the proxy for L7 visibility, then choose whether the proxy→app hop is HTTP or HTTPS/mTLS.

Terminate at the proxy when you want one public certificate surface, one TLS policy, and full HTTP visibility for routing, caching, compression, and WAF logic. If the app must own the certificate, you move toward TCP/TLS pass-through instead and give up many of those proxy features.

The follow-on choice is trust model: plain HTTP to the backend on a trusted network, or re-encrypted HTTPS/mTLS on a stricter one. The deeper mechanics live in Reverse Proxy Fundamentals → SSL / TLS Termination; the design trade-off here is simplicity versus internal trust requirements.

06 · Pitfalls

Common Mistakes

These are the reverse-proxy mistakes that repeatedly cause outages or confusing behaviour in production.

A single proxy with no HA

In production, one proxy on every request is one failure from total outage. Run a cluster behind a load balancer when you need high availability.

Catch-all route above specific routes

In nginx a plain location / does not swallow /api even if it appears first — prefix locations use longest-prefix matching. The real shadowing risk is regex locations: they are checked in file order (first match wins) and override a plain prefix match, so put specific regexes before broad ones and use = or ^~ for paths that must not be captured by a regex.

Caching authenticated responses under a shared key

Leaks one user's data to the next visitor. Vary on session or mark authenticated responses non-cacheable.

Forgetting cert renewal

An expired cert is a hard, total HTTPS outage. Automate renewal and alert days ahead.

Dropping the client's real IP

Backends see the proxy's IP unless you forward it. Set and trust X-Forwarded-For/X-Real-IP — carefully, so it can't be spoofed.

nginxTrust X-Forwarded-For only from known proxies (ngx_http_realip_module). Addresses are RFC 5737 documentation values: replace with your real load balancer/CDN ranges.

set_real_ip_from  192.0.2.0/24;      # the trusted load balancer tier
real_ip_header    X-Forwarded-For;
real_ip_recursive on;                # skip trusted hops, take the first untrusted address

Why it matters: a client can send its own X-Forwarded-For: 198.51.100.7. Each proxy appends the address it saw, so the backend receives 198.51.100.7, 203.0.113.9 when the real client is 203.0.113.9. An app that reads the left-most value is fooled; trusting only hops you control and taking the right-most untrusted entry is not.

Reloading config without validating

A bad config applied to every instance at once is an outage. Run nginx -t and canary changes before full rollout.

07 · Common architecture questions

Common Architecture Questions & Real-World Architectures

Questions that regularly come up in design reviews, answered with the architecture trade-offs behind them.

Swipe to pan

The reference production shape: Internet → Load Balancer → Reverse Proxy Cluster → Backends.

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

Often, depending on the features you need (a cloud L7 load balancer may already cover TLS termination and path routing). The load balancer distributes; the reverse proxy adds SSL termination, static serving, caching, path routing, and security. They're complementary layers, not substitutes.

Is Nginx a reverse proxy, a load balancer, or a web server?

All three, depending on config. That flexibility is why it's everywhere — but in any given deployment, be clear which role it's playing.

Where does the CDN fit?

Usually in front of the proxy. A CDN is a globally distributed network of reverse-proxy-like edge nodes: it can terminate TLS and cache content too, but does so close to users across many regions and can absorb large traffic spikes. The reverse proxy is still valuable as the origin-facing edge tier for local routing, security, and backend integration.

How do big sites lay this out?

Internet → CDN → dedicated load balancer → reverse proxy cluster → service backends, with a private network hiding the backends. Each layer is independently scalable and none is a single point of failure.

Key takeaways

01Reverse proxy and load balancer are complementary layers, used together.
02Nginx is a reverse proxy, LB, and web server — name the role per deployment.
03CDN sits in front of the proxy; the proxy is the origin.
04The reference shape is CDN → LB → proxy cluster → backends on a private network.