What Is a Reverse Proxy? Architecture, Benefits, and Common Use Cases

A reverse proxy is a server-side intermediary that receives client requests before they reach one or more backend servers.

To the client, the reverse proxy looks like the destination. Behind the scenes, it can select a backend, forward the request, receive the backend response, and return that response to the client. In HTTP terminology, RFC 9110 describes a gateway—also called a reverse proxy—as an intermediary that acts like an origin server on the client-facing connection and forwards requests to another server or servers.

That definition matters because a reverse proxy is primarily an architectural role, not one specific protocol or product. NGINX, HAProxy, a cloud load balancer, or an edge service can all perform reverse-proxy functions when deployed in front of an application.

Quick Answer

A reverse proxy sits in front of backend servers and handles inbound client traffic on their behalf.

A typical request path is:

1. A client connects to the public hostname.

2. The reverse proxy accepts the connection.

3. It applies routing, security, caching, or load-balancing rules.

4. It opens or reuses a separate connection to a selected backend.

5. The backend response returns through the proxy to the client.

Common reasons to deploy one include:

• distributing traffic across multiple application servers;
• terminating TLS at a controlled edge;
• routing different hosts or paths to different services;
• caching selected responses;
• shielding backend topology from direct exposure;
• centralizing access control, rate limiting, logging, or security inspection.

None of those capabilities is automatic. A reverse proxy only provides the functions you configure, and poor routing, header, cache, retry, or TLS settings can create new failure modes.

What Is a Reverse Proxy?

A reverse proxy represents the server side of a connection.

The client does not choose a backend server directly. Instead, DNS and network routing send the client to the reverse proxy, which becomes the public-facing endpoint. The proxy then decides where the request should go.

This is why the term “reverse” can be confusing. The network traffic itself is not literally reversed. The name reflects which side the proxy represents:

• a forward proxy represents one or more clients when they connect outward;
• a reverse proxy represents one or more servers when clients connect inward.

How a Reverse Proxy Works

The most useful way to understand reverse-proxy architecture is to separate the client-facing connection from the backend connection.

1. The client reaches the public endpoint

A browser, mobile app, API client, or other user agent resolves the service hostname and connects to the address exposed by the reverse-proxy layer.

The client may have no knowledge of the private backend address or even how many backend servers exist.

2. The reverse proxy accepts the request

The proxy can inspect information available at its layer, such as:

• hostname;
• URL path;
• HTTP method;
• headers;
• source connection details;
• TLS connection properties.

It can then apply routing or policy rules.

3. The proxy selects a backend

The request may always go to one application server, or the proxy may select from a backend pool.

NGINX documents load-balancing methods such as round robin, least connections, and IP-hash routing. Other products expose different algorithms, weights, health checks, or service-discovery integrations.

4. The proxy creates the backend request

The backend request is not necessarily byte-for-byte identical to the client request.

A reverse proxy can:

• rewrite or add headers;
• change the backend host or port;
• normalize paths;
• buffer requests or responses;
• select a different upstream protocol where supported.

For example, NGINX's reverse-proxy documentation describes proxy_set_header for controlling headers sent to an upstream server.

5. The response returns through the proxy

The backend sends its response to the reverse proxy. The proxy may pass it through, cache it, modify selected headers, compress it, or apply other configured behavior before sending the response to the client.

Reverse Proxy vs Forward Proxy

Forward and reverse proxies are both intermediaries, but they are deployed for different sides of a connection.

A forward proxy is therefore not just a reverse proxy pointed in the other direction. The trust model, operator, routing decisions, and deployment objective are different.

Reverse Proxy Architecture: The Important Layers

A production reverse-proxy design usually has more than one conceptual layer.

Public endpoint

This is the hostname and network address clients can reach.

For an edge service, DNS may route the public hostname to the provider's network. Cloudflare documents that proxied DNS records route HTTP/HTTPS traffic through Cloudflare before it reaches the origin.

Reverse-proxy or gateway layer

This is where inbound connections terminate and routing decisions are made.

Depending on the product and configuration, this layer may also handle:

• TLS;
• load balancing;
• caching;
• request filtering;
• authentication;
• rate limits;
• logging and metrics.

A reverse proxy is not required to perform every one of these jobs.

Backend pool

The backend may be:

• one origin server;
• multiple replicas of the same application;
• different services selected by host or path;
• a legacy application behind a modern public endpoint.

The proxy can hide this internal topology from clients, which makes backend changes easier to perform without changing the public URL.

Client identity and forwarding metadata

Once a reverse proxy sits between the client and application, the backend's direct network peer is normally the proxy.

If the application needs the original client IP, scheme, or host, the proxy may add forwarding metadata. The standardized Forwarded header can carry information such as the original client address and protocol. In practice, X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto are also widely used.

This metadata creates a trust problem, not just a convenience.

MDN's X-Forwarded-For guidance warns that values not added by trusted proxies can be spoofed. If an origin is directly reachable from the internet, an application cannot safely treat an arbitrary incoming X-Forwarded-For chain as authoritative for security decisions.

Common Reverse Proxy Capabilities

Load balancing

A reverse proxy can distribute requests across multiple backends.

This is one of the most common deployments, but “reverse proxy” and “load balancer” are not perfect synonyms. Reverse proxy describes the intermediary role; load balancing describes one routing function that the intermediary may perform.

A single-backend reverse proxy is still a reverse proxy.

TLS termination

A reverse proxy can terminate HTTPS on the client-facing connection.

For example, AWS Application Load Balancer documentation states that an HTTPS listener uses a server certificate to terminate the front-end connection and decrypt client requests before forwarding them to targets.

That does not mean the backend leg must be unencrypted. A deployment can terminate client-side TLS at the proxy and then establish another protected connection to the backend. The correct design depends on the network boundary and threat model.

Caching

A reverse proxy can cache eligible responses so repeated requests do not always reach the backend.

NGINX's content-caching documentation describes storing proxied responses and reusing them for later requests. HTTP caching still needs correct cache-control policy: personalized or sensitive responses must not be shared merely because a proxy is capable of caching them.

Caching is therefore an optional behavior, not an inherent property of every reverse proxy.

Buffering and connection management

A proxy can absorb differences between slow clients and faster application servers.

NGINX, for example, documents response buffering as a way to allow the upstream server to finish processing while the proxy continues sending data to a slower client.

This can improve resource isolation, but it can also be undesirable for streaming or highly interactive responses, where buffering policy needs to match the application.

Centralized routing and policy

Where supported, the proxy can centralize host/path routing, authentication integration, rate or request limits, logging, and security filtering. These are configured capabilities, not inherent properties of every reverse proxy.

Benefits of a Reverse Proxy

1. Backend abstraction

Clients can use a stable service endpoint while backend hosts, ports, or replicas change behind the proxy. This does not automatically make those backends hidden or unreachable by other routes.

2. Scalability

When a proxy supports load balancing, multiple backend instances can share traffic.

This allows the application tier to scale horizontally rather than forcing every request through one server.

3. Reliability

Reverse proxies and load balancers can use backend health information to avoid unhealthy instances.

HAProxy's health-check documentation describes active and passive checks and removing failed servers from the load-balancing rotation until they recover.

That improves routing decisions, but it does not make the proxy itself failure-proof. The proxy layer also needs redundancy if it is a critical entry point.

4. Centralized TLS and certificate handling

Terminating TLS at the proxy can move public certificate management away from every backend instance.

This can simplify operations when many application servers serve the same public hostname.

5. Performance controls

Caching, buffering, connection reuse, compression, or load distribution can improve performance for suitable workloads and configurations. Adding a reverse proxy alone does not guarantee a speed gain.

6. A controlled security boundary

A reverse proxy can reduce direct backend exposure and provide a consistent enforcement point, but only if the origin cannot simply be reached around it.

Common Reverse Proxy Use Cases

Multi-server web applications

A public hostname points to the reverse-proxy layer, which distributes traffic across multiple application instances.

This is the classic combination of reverse proxy and load balancing.

Microservices and path-based routing

A reverse proxy can route different hostnames or URL paths to different internal services. This is one possible routing pattern, not a requirement of reverse-proxy architecture.

TLS offload at the application edge

The proxy manages the public HTTPS connection and certificates while backend services operate behind that controlled edge.

If the internal network requires encryption too, the proxy can connect to backends over HTTPS or another protected transport supported by the platform.

Caching in front of an origin

A reverse-proxy cache can serve reusable content without contacting the origin for every request.

This can reduce origin load and improve response time for cacheable resources, but cache rules must account for authorization, cookies, personalization, and freshness.

Protecting legacy or internal services

RFC 9110 notes that gateways are often used to encapsulate legacy or untrusted information services.

A reverse proxy can expose a controlled public interface while the backend remains on an internal network or uses a different application interface.

Edge services and CDNs

Some CDN and edge-security products operate as large distributed reverse-proxy networks.

Clients connect to the edge, while the edge decides whether to answer from cache, apply policy, or forward the request to the origin.

Reverse Proxy vs Load Balancer

The two concepts overlap heavily.

A reverse proxy answers the architectural question:

What component receives the client connection and communicates with the backend on the server's behalf?

A load balancer answers the traffic-distribution question:

How should requests or connections be distributed among multiple backends?

A product can do both. NGINX, HAProxy, and cloud application load balancers commonly combine these roles.

But the terms should not be treated as identical:

• a reverse proxy can forward everything to one backend;
• a load balancer's defining job is selecting among multiple targets;
• a reverse proxy may additionally perform TLS, caching, header rewriting, or application routing.

Security and Reliability Pitfalls

A reverse proxy can improve an architecture, but it also becomes part of the application's trust boundary.

Trusting forwarded client IPs incorrectly

Do not use the leftmost value in X-Forwarded-For for security-sensitive decisions without understanding the trusted proxy chain.

A client can supply spoofed forwarding headers unless the edge removes or overwrites untrusted values and the application knows which proxy hops it can trust.

Leaving the origin directly reachable

If the public reverse proxy performs access control or filtering but the origin still accepts arbitrary public connections, users may bypass the intended entry point.

Restrict direct origin access where the design requires the proxy to be authoritative.

Assuming TLS termination equals end-to-end encryption

When the proxy terminates TLS, the client-to-proxy connection is protected.

The proxy-to-backend connection is a separate security decision. Use backend TLS when the internal leg also requires transport encryption.

Retrying unsafe requests

Retries can improve resilience after short-lived failures, but retry policy must preserve HTTP semantics.

RFC 9110 states that a proxy must not automatically retry non-idempotent requests. A careless retry policy around operations such as purchases or state-changing POST requests can duplicate effects.

Caching personalized content

Shared proxy caches must not reuse private responses across users unless the response is explicitly safe for shared caching.

Review Cache-Control, cookies, authorization behavior, and the proxy's own cache rules together.

Creating a new single point of failure

If every request depends on one reverse-proxy instance, failure of that instance can take down otherwise healthy backends.

Production designs commonly add redundancy, failover, or a managed service at the proxy layer itself.

Reverse Proxy Deployment Checklist

Before putting a reverse proxy in production, verify the following:

• Public entry point: Which hostname and ports are exposed?
• Origin reachability: Can clients bypass the proxy and connect directly to the backend?
• Routing: Which hosts, paths, or services map to which backends?
• Load balancing: If multiple backends exist, how are they selected?
• Health checks: What makes a backend healthy enough to receive traffic?
• TLS: Where does TLS terminate, and is the backend connection also encrypted?
• Forwarded headers: Which proxy hops are trusted to set client IP, host, and scheme metadata?
• Retries: Which failures can be retried without changing request semantics?
• Caching: Which responses are safe to store and share?
• Timeouts and buffering: Do they fit streaming, uploads, and long-running requests?
• Logging: Can you correlate the client-facing request with the backend request?
• Proxy redundancy: What happens if the reverse-proxy layer itself fails?

A reverse proxy is most valuable when these decisions are explicit rather than inherited from defaults.

Final Takeaway

A reverse proxy is best understood as a server-side gateway role.

It accepts client traffic at a public endpoint and then communicates with backend servers on the application's behalf. From that position, it can provide load balancing, TLS termination, caching, routing, buffering, health-aware failover, and centralized policy controls.

The architectural value comes from separating the public service interface from backend implementation details.

The operational risk comes from the same place: the proxy becomes a trust and availability boundary.

A sound deployment therefore does more than install a proxy. It defines:

1. which traffic must pass through it;

2. how backends are selected;

3. where TLS begins and ends;

4. which forwarding metadata is trusted;

5. how health checks and retries behave;

6. what can be cached;

7. how the proxy layer itself remains available.

That is the difference between simply placing another server in the request path and designing a reliable reverse-proxy architecture.

Sources

• RFC 9110 describes a gateway—also called a reverse proxy
• NGINX documents load-balancing methods
• NGINX's reverse-proxy documentation
• Cloudflare documents
• Forwarded header
• MDN's X-Forwarded-For guidance
• AWS Application Load Balancer documentation
• NGINX's content-caching documentation
• HAProxy's health-check documentation