What a Reverse Proxy Is (and Why Almost Every Site Uses One)

Behind almost every site you visit there’s a component you never notice, precisely because it does its job by staying out of sight: the reverse proxy. It isn’t the program that builds the pages, nor the database that stores the data. It’s the intermediary that sits in front of everything else and decides who gets in, how, and toward which service. Understanding what it is helps you read a site’s architecture instead of picturing it as a black box.

What a reverse proxy is, in plain terms

A proxy is, literally, an intermediary: a component that sits between two parties and passes messages from one to the other. A reverse proxy is an intermediary that sits in front of one or more application servers. The visitor talks to the reverse proxy; the reverse proxy forwards the request to the right application, collects its response, and hands it back to the visitor. The client, that is the browser, never talks directly to the server that actually builds the page.

A useful picture is the front desk of an office. Someone arriving doesn’t wander the corridors looking for the right person: they go to the reception desk, which routes the request to whoever should handle it and brings the answer back. The desk is a single point of contact for many different offices. A reverse proxy does the same thing for web services.

The difference from a forward proxy

The word “proxy” on its own causes confusion, because there are two opposite kinds. The difference is which side the intermediary stands on.

A forward proxy sits in front of clients. It’s the intermediary a corporate network or a VPN places in front of users’ computers: when someone browses, the request goes through the forward proxy first, which then talks to the outside sites on their behalf. It’s used to control and filter outbound traffic and, often, to hide the identity of the person browsing.

A reverse proxy sits in front of servers. It’s the intermediary a site’s operator places in front of their own applications. MDN’s documentation captures the contrast well: a forward proxy acts on behalf of clients and can hide their identity, whereas a reverse proxy can hide the identity of the servers. Same basic idea, opposite side: one protects who asks, the other protects who answers.

A single entry point for many services

The most concrete reason a reverse proxy is so common is that it provides a single entry point for many services. On the internet a site is reachable on two standard ports: 80 for HTTP and 443 for HTTPS. But behind a single domain there can be several applications: the public site, the customer area, an API for the mobile apps, an admin panel.

The reverse proxy listens on that one public port and, by looking at the requested domain name or path, decides which internal application each request goes to. The applications, for their part, listen only on the machine’s local network, without being directly exposed to the internet. A minimal example with Nginx, one of the most widely used reverse proxies, makes the idea concrete:

server {
    listen 443 ssl;
    server_name site.example.com;
    # ...TLS certificates...

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Here the proxy receives the encrypted connections from the outside and forwards them to an application running locally on port 3000. The visitor sees a single address; behind the scenes there can be a whole set of services.

TLS: encryption handled in one place

Today web traffic travels encrypted with TLS, the protocol behind the HTTPS padlock. Handling encryption requires certificates, keys and configuration, and it isn’t work you want to duplicate in every single application.

The reverse proxy solves this with TLS termination: it’s the one that handles the encrypted “handshake” with the browser, decrypts incoming requests and encrypts outgoing responses, so the servers behind it don’t have to. The certificates live in one place, the security configuration is updated in one place, and the internal applications can talk in plain HTTP on the local network, focusing on their own job.

Caching and compression: less repeated work

A reverse proxy can also keep a copy of responses it has already computed. That’s caching: if many users ask for the same image or the same page, there’s no need to regenerate it every time. The first request pays the full cost toward the application; the following ones get the ready-made copy, much faster and without straining the origin server.

At the same level sits compression: the proxy can compress text, HTML and data before sending them, reducing the bytes that travel over the network and therefore load times. These are optimizations that are convenient to set up once, in front of everything, instead of reimplementing them in each application.

Load balancing

When a single server isn’t enough to handle the traffic, you run several copies of the same application and spread the requests across them. This task, load balancing, is one of the classic uses of a reverse proxy.

The proxy decides which server to forward each request to, according to a rule. Nginx, for example, uses round robin by default, distributing requests to each available server in turn while taking any weights into account; alternatively it can send each request to the server with the fewest active connections (least connections) or tie a client to the same server based on its address (ip hash). The benefit is twofold: you handle more traffic and, if one server fails, the others keep responding.

Security: a filter in front of the application

Placing an intermediary in front of the servers also has defensive value. The first benefit is a smaller exposed surface: the applications aren’t reachable directly from the internet, only through the proxy. Anyone trying to attack them doesn’t even know their real address, because the only thing that ever answers is the intermediary.

The second is that the reverse proxy becomes the natural place to concentrate controls: limiting the number of requests to block abuse (rate limiting), filtering suspicious traffic, applying access rules. Doing this in one spot, in front of everything, is simpler and more robust than scattering the same defenses across every application.

Nginx and the others

Nginx is perhaps the most cited example, but a reverse proxy is a role, not a product. The same job is done by software like HAProxy, Apache, Caddy, Traefik or Envoy, by the load balancers cloud providers offer and, at global scale, by CDNs such as Cloudflare’s, which are themselves reverse proxies in front of millions of sites.

It’s worth noting that the pattern isn’t tied to HTTP alone: a reverse proxy can forward requests to applications over other protocols too, and in fact Nginx supports, besides HTTP, mechanisms like FastCGI, uwsgi, SCGI, memcached and gRPC. The concept stays the same regardless of the tool you pick.

In short

A reverse proxy is the intermediary that sits in front of web applications and acts as the single point of contact toward the outside world. From there it handles TLS encryption, caching and compression, spreads the load across several servers, and concentrates security controls, keeping the applications shielded from direct exposure. It isn’t a flashy component and almost no user knows it’s there, but that’s exactly why almost every site uses one: it solves, in a single place, a set of problems that every application would otherwise have to face on its own.

# What a Reverse Proxy Is (and Why Almost Every Site Uses One)