Programming · Servers · Networking

What is a reverse proxy?

Once you run more than one app on a server — a website, an API, maybe a few containers — you hit a practical problem: visitors all arrive on ports 80 and 443, but each app listens somewhere different. A reverse proxy is the standard answer. This guide explains what a reverse proxy is, how it differs from the proxy you may already know, and why almost every production setup has one.

The short definition

A reverse proxy is a server that sits in front of one or more backend servers, receives every incoming client request, and forwards it to the appropriate backend — then returns that backend's response to the client. To the visitor, the reverse proxy is the website: they only ever talk to it, and they never see the servers behind it. The word "reverse" matters, and the next section explains why.

Reverse proxy vs forward proxy

A plain (forward) proxy sits in front of clients. When your browser is configured to use one, your requests go out through the proxy on your behalf — it acts for the people making requests. A reverse proxy is the mirror image: it sits in front of servers and acts on their behalf. Clients connect to it thinking it is the real server, and it decides which backend actually handles each request. Same idea of a middleman, opposite side of the conversation.

What you actually use a reverse proxy for

• Routing by hostname or path: send api.example.com to your API and example.com to your website, even though both run on the same machine.
• TLS termination: handle HTTPS certificates in one place so each backend can speak plain HTTP internally and you manage certificates once.
• Caching: store and serve frequent responses directly, so the backend is not hit for every request.
• Buffering and protection: absorb slow clients, enforce limits, and hide the backends' real addresses behind one public entry point.

In practice the routing and TLS jobs alone are reason enough: they let you host several apps on one VPS cleanly, with HTTPS, behind a single address.

Reverse proxy vs load balancer

These overlap, which is why people confuse them. A load balancer has one specific job: spread incoming traffic across several identical backends so no single one is overwhelmed. A reverse proxy is the broader concept — it forwards requests and can do many things (routing, TLS, caching), and distributing load across backends is one of them. So a load balancer is essentially a reverse proxy focused on the balancing task. Most modern reverse proxies can also load-balance, while a dedicated load balancer may do little else.

The common tools

The most widely used reverse proxies are Nginx, Caddy, HAProxy and Traefik. Nginx is the long-standing default and is extremely fast at serving and proxying. Caddy is popular because it obtains and renews HTTPS certificates automatically with almost no configuration. Traefik is built for container and Kubernetes setups, where it discovers services as they come and go. HAProxy is favoured where high-volume load balancing is the priority. Cloud providers also offer managed reverse proxies and load balancers as a service.

A minimal example

A reverse proxy config is mostly a short list of rules. In Nginx, sending requests for a host to an app running locally on port 3000 looks like this:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

That is the whole idea: requests for example.com arrive at Nginx on port 80, and Nginx forwards them to your app on port 3000, passing along the original host. Add a TLS block and a second server for your API, and one machine cleanly serves several apps over HTTPS.

The honest trade-offs

A reverse proxy adds one more moving part. It becomes a single point that every request flows through, so if it goes down everything behind it is unreachable — which is why production setups run it reliably and sometimes in pairs. It also adds a small amount of latency and one more config file to understand. For a single small app that already listens on port 443, you may not need one at all. But the moment you host more than one service, want HTTPS handled in one place, or plan to scale, a reverse proxy quickly pays for itself.

Frequently asked questions

Browse more clear explainers in our guides index.