What Is a Reverse Proxy and How Does It Work?

A reverse proxy is an intermediary that accepts client connections from the public internet and relays them to one or more origin servers on a private network. To the client, the reverse proxy is the website. The browser connects to the proxy's IP address and never learns the address, count, or location of the servers doing the real work.

The word "reverse" marks the direction. A forward proxy stands in front of clients and represents them to the wider internet. A reverse proxy stands in front of servers and represents them to arriving clients. Same intermediary role, opposite side of the conversation. Routing a reverse proxy is one job in a broader family, so if you want the parent concept first, read what is a proxy server.

Under HTTP semantics (RFC 9110), this is the "gateway" role: the proxy acts as the origin server to the client while translating and forwarding to upstream servers behind it. Those origin servers usually live on private ranges like 10.0.0.0/8 or 192.168.0.0/16 and hold no public route at all. Only the proxy is reachable from outside. For how private and public addresses interact in this setup, see how proxy servers and IP addressing work together.

The request path is short and predictable:

1. DNS for example.com resolves to the reverse proxy's public IP, not the application server's.
2. The client opens a TCP and TLS connection to the proxy.
3. The proxy inspects the request (Host header, URL path, cookies, client IP) and picks a backend using its routing rules.
4. It opens or reuses a connection to that backend on the private network and forwards the request.
5. The backend processes it and returns a response to the proxy.
6. The proxy relays the response to the client on the connection it is still holding open.

Because every request and response crosses this one point, the proxy is the natural place to enforce policy. Encryption, routing, caching, and filtering all happen here before any application code runs. The proxy also rewrites headers so the backend keeps useful context: adding X-Forwarded-For lets your app read the real client IP even though it only ever talks to the proxy over the loopback or private link.

The two look similar on a diagram but face opposite directions. The difference is which side the proxy represents and whose IP it hides.

You deploy a reverse proxy to protect, scale, and optimize traffic coming in to your servers. You use a forward proxy to control or anonymize traffic going out from your clients. Both can coexist: a company might run a forward proxy for employee web access and a reverse proxy in front of its customer-facing app. For the mirror image of everything on this page, read what is a forward proxy. If you are weighing client-side privacy tools instead, proxy vs VPN covers that comparison.

These overlap enough that vendor docs blur them, but they are not the same thing. A load balancer solves one problem, traffic distribution. A reverse proxy does that plus everything else at the edge.

Most reverse proxies can act as load balancers; most dedicated load balancers cannot act as full reverse proxies. An "Application Load Balancer" like AWS ALB is the fuzzy middle case: it terminates TLS, routes by host and path, and runs WAF rules, so it behaves much like a Layer 7 reverse proxy despite the label.

nginx is the most common self-hosted choice. A minimal config that balances two backends and terminates TLS looks like this:

upstream app_backend {
    least_conn;
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass         http://app_backend;
        proxy_http_version 1.1;
        proxy_set_header   Host            $host;
        proxy_set_header   X-Real-IP       $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

That block does four jobs at once: it terminates TLS on port 443, balances requests across two backends with least_conn, forwards the real client IP in X-Forwarded-For, and keeps the origin IPs (10.0.0.11 and 10.0.0.12) off the public internet. One gotcha catches people at scale: leave out proxy_http_version 1.1 and nginx falls back to HTTP/1.0, which drops keep-alive and forces a fresh TCP handshake to the backend on every single request. Under load that exhausts ephemeral ports for no reason, so set it explicitly. For choosing the listen port, proxy ports explained covers 80, 443, 8080, and the rest.

Reach for one when any of these are true:

• You run more than one backend. A reverse proxy is the cleanest way to load balance and health-check them behind a single hostname.
• You want centralized TLS. One certificate, one policy, one renewal job for the whole fleet instead of drift across servers.
• You need caching or compression without editing application code, to cut backend load and bandwidth.
• You want a single security chokepoint for WAF rules, rate limiting, and DDoS absorption.
• You must hide origin servers so attackers can only reach a hardened edge, not your app's private network.

For a small single-server hobby project, a reverse proxy is optional. The moment you scale past one backend, care about uptime, or face real attack traffic, it stops being optional and becomes the standard front door for the whole system.