Reverse Proxy Fundamentals

A reverse proxy is a server that sits in front of your application servers, receives every client request on their behalf, and forwards it to whichever backend should handle it — then relays the response back. Nginx is a common choice for the role, and the minimal configuration below shows the idea.

From the client's point of view, the reverse proxy is the application. The browser connects to one address, sends a request, and gets a response. It has no idea that behind that address there might be one app server or fifty, that the response came from a cache, or that a file was served straight from the proxy's own disk. That indirection is the whole point.

The core responsibilities

Every reverse proxy story starts the same way: a client talking directly to an application server, and that one server quietly being asked to do far too much.

The direct-access pain

When a client hits your app directly, four problems appear almost immediately. First, every server manages its own TLS certificate — three servers means three renewal calendars and three ways to expire. Second, the app wastes CPU serving static files like images and stylesheets that never change. Third, every server is exposed to the internet, so each is a separate attack surface. Fourth, as you add an admin panel, an API, and a static site, routing logic gets tangled into each app or hardcoded into clients.

The word "proxy" hides two opposite roles. The direction it faces is what makes it forward or reverse.

A forward proxy sits in front of a set of clients. When those clients want to reach the internet, they send their requests through the forward proxy — which can filter, log, cache, or anonymise the outbound traffic. A corporate web filter or a VPN egress is a forward proxy. It works on behalf of the client, and the destination server usually has no idea the proxy exists.

A reverse proxy sits in front of a set of servers. When clients out on the internet want to reach your application, they hit the reverse proxy, which forwards to the right backend. It works on behalf of the server, and the client usually has no idea the proxy exists. Same machinery, opposite direction, opposite beneficiary.

A reverse proxy can load-balance across backends, but that is one capability inside a broader edge role. A load balancer's defining job is traffic distribution.

A dedicated load balancer is built around backend selection: maintain a pool of healthy targets, choose where a new connection or request goes, and keep traffic flowing when a target fails. Some operate at L4, some at L7, and the richer ones add health-checked pools, stickiness, and distribution policies — but distribution is still the centre of gravity. See Load Balancer Fundamentals for the full mechanics.

A reverse proxy is the server-facing HTTP(S) entry point for an application. It terminates client connections, forwards them to one or more origins, and often adds TLS termination, compression, caching, static asset handling, and path/host routing. If several origins sit behind it, it can also balance across them — but that is a feature of the proxy, not its whole definition.

An API gateway is usually built on reverse-proxy technology, but tuned for API-specific policy rather than general web edge duties.

A reverse proxy handles transport and HTTP-level concerns for whatever sits behind it: terminate TLS, compress responses, cache safe content, serve static assets, and route by host or path to one or more backends. It is a general-purpose edge intermediary for web traffic, not just a one-service fan-out box.

An API gateway takes that proxy foundation and adds API-facing concerns such as authentication, authorization, per-consumer rate limiting, request/response transformation, aggregation, and versioning. So the boundary is not "proxy" versus "gateway" as unrelated categories; it is general HTTP edge proxying versus API product policy. See API Gateway Fundamentals for the API-specific layer.

One request through a reverse proxy is really two connections and four hops, with the proxy as the pivot in the middle.

The client opens a connection to the proxy and sends its request — hop one. The proxy opens its own, separate connection to a backend and forwards the request — hop two. The backend does the real work and replies to the proxy — hop three. The proxy relays that response down the client-side connection — hop four.

The two-connection design is what unlocks everything else. Because the client-side and backend-side connections are independent, the proxy can terminate TLS on one side and speak plain HTTP on the other, pool and reuse backend connections, buffer slow clients, and swap which backend it talks to without the client ever reconnecting.

HTTPS has to be decrypted somewhere. Doing it once at the proxy instead of on every backend is one of the biggest operational wins a reverse proxy gives you.

With TLS termination (often called TLS offload), the client completes the TLS handshake with the reverse proxy. The public certificate and private key live on that proxy tier, so it is the component that decrypts the request and gains full L7 visibility for routing, caching, compression, WAF rules, and logging.

From the proxy inward you choose the trust model. In many deployments the proxy forwards plain HTTP across a private network to simplify backend operations and remove handshake CPU from app servers. In stricter environments the proxy terminates public TLS and then opens a new HTTPS or mTLS connection to the backend, preserving encryption on the internal hop too.

The operational payoff is still the same: certificate lifecycle, TLS versions, cipher policy, OCSP stapling, and renewals are centralised on the edge tier instead of repeated on every origin server. Pure TCP pass-through is different — the proxy never decrypts, so the backend keeps the cert and the proxy loses most HTTP-aware features.

A huge fraction of web traffic is static files that never change per request. Making your application generate them is a waste — the proxy can serve them itself.

When a request for /logo.png arrives, the proxy matches it against its static rules, finds the file on its own disk, and returns it — the application server is never contacted. A compiled proxy like Nginx serving a file from disk is dramatically faster and cheaper than a language runtime doing the same thing.

The effect on backend load is immediate. All that repetitive static traffic is absorbed at the edge, leaving the application free to spend its CPU on the dynamic requests only it can compute. Splitting static from dynamic at the proxy is often the single biggest reason teams put Nginx in front of an app.

A real site is rarely one app. The proxy can front several services behind one domain and route each request by its URL path.

The proxy inspects each request's path and forwards it to the backend that owns that prefix — /api/* to the API service, /admin to the admin panel, /static/* to the assets. To the outside world it is a single, coherent site; behind the proxy it is several independent services that can be deployed, scaled, and owned by different teams.

If ten thousand people ask for the same page in a minute, why regenerate it ten thousand times? The proxy can remember the response and hand out copies.

On a cache miss the proxy has nothing stored, so it forwards to the backend, then keeps a copy of the response tagged with a time-to-live before sending it on. On a subsequent cache hit, while that copy is still fresh, the proxy answers immediately and the backend is never touched. Reverse proxies really do cache responses themselves — for example, Nginx can do this with proxy_cache; caching is not unique to CDNs.

Hit ratio is the whole game. At a 90% hit ratio your backend sees a tenth of the traffic and users get near-instant responses. A reverse-proxy cache usually lives in one deployment or region; a CDN applies the same idea across many geographically distributed edge locations. The classic mistake is caching content that shouldn't be shared — per-user or rapidly-changing data — so caching is always about choosing what is safe to cache and for how long.

Because the proxy is the only thing exposed to the internet, it is the perfect place to defend the whole system.

The backends sit on a private network with no public address, so nobody outside can even attempt to reach them — only the proxy can. Hiding the internal topology matters: an attacker cannot target a box they cannot see or address.

Because every request flows through it, the proxy is also the natural place to inspect and reject bad traffic. It can block known exploit patterns, enforce IP allow-lists, apply connection and request rate limits, and add security headers — dropping hostile requests at the edge before they ever reach an application that would have to parse them. API gateways may still add per-consumer quotas or auth policy, but coarse perimeter filtering belongs naturally at the reverse proxy.

A single proxy sits on every request, which makes it a single point of failure. At scale you run several and put a load balancer in front of them.

If everything routes through one proxy and it dies, the whole site goes dark — no SSL, no routing, no cache. The fix is to run multiple identical proxy instances as a cluster and place a dedicated load balancer in front, spreading traffic across them and health-checking each one. If a proxy fails, the load balancer simply stops sending it traffic and users never notice.

Each layer scales independently and horizontally. Under load you add proxy instances; the backends scale on their own axis. Because proxies are mostly stateless (cache aside), adding or removing one is cheap.

Put every piece together and you get the shape behind most large web systems.

Traffic from the internet often hits a CDN or dedicated load balancer first, which then spreads it across a resilient tier of reverse proxies. That proxy tier terminates TLS, serves static files, caches responses, routes by path, and filters hostile traffic — then forwards the surviving dynamic requests to the backend services. Every layer is independently scalable and is designed so that none is a single point of failure.