Reverse Proxy Explained: The Server in Front of Your Servers

Visitors to your site connect to one address, but behind it your application is a dozen processes, and you would rather they never learn the addresses, the ports, or the version numbers. Something has to receive every connection, speak TLS, decide where each request goes, and answer for the whole fleet. That something is a reverse proxy.

A reverse proxy is a server that sits in front of one or more application servers and forwards client requests to them, then returns the responses. Clients talk only to the proxy; the servers behind it are invisible to the outside world. It is “reverse” because the proxy acts on behalf of the server rather than the client; the direction of the proxying is flipped.

Forward proxy vs reverse proxy

The difference is which side does the hiding:

• A forward proxy acts for clients. It sits in front of clients (a corporate egress filter, a privacy proxy, a caching proxy on an office network) and forwards their requests to servers. The server sees the proxy, not the client. Companies use forward proxies to filter, log, and control outbound traffic.
• A reverse proxy acts for servers. It sits in front of servers and receives requests that clients believe they are sending to the service itself. The client sees only the proxy, never the servers. Operators use it to terminate TLS, route, protect, and front their infrastructure.

Same mechanism, opposite directions of trust: a forward proxy hides clients from servers; a reverse proxy hides servers from clients.

What a reverse proxy does

TLS termination

The proxy holds the certificates, performs the handshakes, and speaks plaintext (or re-encrypted connections) to the backend. Certificates are managed in one place instead of on every node, and backend servers spend their cycles on application work rather than cryptography.

Routing

Requests are dispatched by path and header: /api/ to the service tier, /static/ served locally or shipped to object storage, /admin restricted to an internal network. Routing by request content makes the pattern the natural substrate for microservices (one public entry point fanning into many services) and, extended with authentication, quotas, and transformation, it becomes the API gateway pattern.

Security and isolation

Backends bind to private addresses and never accept direct outside connections. The proxy becomes the single place to filter hostile traffic, enforce access rules, and apply rate limits before requests consume backend capacity. A slow or abusive client exhausts the proxy’s buffers, not your application workers.

Buffering and slow clients

A client on a bad mobile connection reads a response at a trickle. Spoken directly to an application server, one of the server’s workers is pinned for the entire trickle. A buffering proxy reads the backend’s answer quickly and drips it to the client at whatever pace the client can take, backend workers stay free.

Compression, caching, and logging

Compress responses once at the edge rather than in every service; serve a cached copy of cacheable responses at the proxy layer; and record one consistent access log with real timing for every request, whichever backend handled it. Edge caching at global scale is a different job; a CDN is a distributed fleet of front doors placed near users; a reverse proxy is your site’s single front door.

Reverse proxy vs load balancer

The two terms are used interchangeably and should not be, because they answer different questions:

• A load balancer distributes traffic across multiple servers; that is its whole purpose: algorithms, health checks, even distribution. It can do its job at L4 without knowing anything about HTTP.
• A reverse proxy fronts servers; TLS, routing, security, buffering, and performs those functions whether there is one server behind it or fifty.

The practical reality: the functions overlap, and the same products do both; nginx reverse-proxying across three upstreams with health checks attached is load balancing. The distinction that survives is about intent: proxying is what happens to a request at the entrance; balancing is where it goes after that. A production stack usually gets both; the distribution side (algorithms, health checks, L4 vs L7) is covered in load balancing in system design.

A minimal nginx reverse proxy

The pattern, in the configuration language most people first meet it in:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Read it as a specification of the pattern: TLS terminates at the proxy (the certificates live here, not in the applications); requests route by path to two different backend processes; and the X-Forwarded-For and X-Forwarded-Proto headers carry the information the proxy consumes (the client’s address and the original scheme) to backends that would otherwise see only the proxy’s. Backends that ignore these headers log every request as coming from one address: the proxy itself.

Real-world usage

The pattern is nearly universal. nginx in front of application servers is the canonical small-stack design; HAProxy fronts fleets where distribution dominates; Envoy is the substrate of service meshes, reverse-proxying every sidecar-to-service hop in a microservices architecture; and cloud load balancers are, functionally, managed reverse proxies with balancing folded in. Does a public service need one? Almost always; TLS management alone justifies it, and isolation is worth the rest. The exceptions are internal tools and single-process systems, where a fronting layer would add a failure domain without adding a function.

Failure modes

• The proxy is a single point of failure. One front server caps the availability of everything behind it; the same reasoning that gives balancers HA pairs applies to proxies; the availability math is in availability vs reliability vs durability.
• Buffering that breaks streaming. The buffering that protects backends from slow clients also queues streaming responses (server-sent events, long polling, progressive video) unless those paths are configured to pass through unbuffered.
• Header loss. Without X-Forwarded-For and X-Forwarded-Proto, backends log every request as arriving from one address (the proxy’s) and misjudge the original scheme. The logs lie quietly for months.
• Timeout mismatches. A proxy timeout shorter than the backend’s slowest legitimate operation kills healthy requests; one longer than the client’s patience leaves users hanging on requests the proxy is still patiently waiting out.

Common mistakes

• Managing certificates on every backend instead of terminating at the proxy. Certificate sprawl, handshake cost in every process, and no single place for TLS policy.
• Proxying without forwarding client information. The X-Forwarded-* headers are the difference between backend logs that describe your traffic and logs that describe your proxy.
• One proxy, no redundancy. The front door fails while everything behind it is healthy; the same failure-domain analysis applies as to any single node.
• Adding proxy hops between internal services. Proxying at the perimeter earns its keep; proxying every internal call adds a hop of latency and a failure domain per pair of services. Front the edges, not the interior.

FAQ

What is a reverse proxy?

A server that sits in front of your application servers and forwards client requests to them, then returns the responses. Clients connect only to the proxy; the backends are invisible to the outside world. It typically handles TLS termination, path-based routing, security filtering, and buffering on behalf of the servers behind it.

What is the difference between a forward proxy and a reverse proxy?

Which side they act for. A forward proxy sits in front of clients and hides them from servers (corporate egress filtering, privacy proxies). A reverse proxy sits in front of servers and hides them from clients. Same mechanism, opposite directions of trust.

What is the difference between a reverse proxy and a load balancer?

A load balancer’s core job is distributing requests across many servers, algorithms and health checks. A reverse proxy’s core job is fronting; TLS, routing, security, buffering, which it does even with a single backend. The same software often performs both, and in production the functions usually live in the same layer.

Do I need a reverse proxy?

For any public service, almost always: TLS management, backend isolation, and a single enforcement point for security policy justify the hop. For internal tools or single-process deployments, a proxy can add a failure domain without adding a function; fronting earns its keep when there is something worth fronting.

Does a reverse proxy improve security?

It improves the security architecture: backends are unreachable directly, hostile traffic meets a dedicated filtering layer, rate limits apply before backend capacity is consumed, and slow-client abuse dies in proxy buffers. It is not a substitute for securing the application itself; a proxy in front of a vulnerable backend is a well-guarded door on an unlocked house.

Related articles

• Next read: API gateway in system design, what the pattern becomes when fronting grows into policy.
• load balancing in system design, the distribution half of the front server’s job.
• rate limiting in system design; the policy a proxy is the natural place to enforce.
• how a CDN works; fronting at planetary scale, before traffic ever reaches your proxy.
• microservices architecture; the style that multiplies the front doors worth having.

Last updated on 14 September 2026