What is a reverse proxy and why would you use one?

A reverse proxy is a server that sits in front of your application servers. Clients talk to it as if it were the real site, and it forwards each request to a backend. Teams use it for TLS termination, load balancing, caching and a single place to apply security controls.

What does the standard say?

HTTP's core specification, RFC 9110, describes the pattern under the name gateway. It says a gateway, also called a reverse proxy, is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. The RFC lists typical uses: encapsulating legacy or untrusted information services, improving performance through accelerator caching, and partitioning or load balancing HTTP services across several machines.

The RFC also notes that a gateway may talk to its inbound servers using any protocol it chooses, which is why a proxy can accept HTTPS from the internet and speak plain HTTP, or another protocol, to a backend.

How is it different from a forward proxy?

A forward proxy serves clients. It sits on the user's side and sends their requests out to the internet. NIST's glossary, quoting CNSSI 4009, defines a proxy server as a server that services the requests of its clients by forwarding those requests to other servers. A reverse proxy flips the viewpoint: it serves the servers. The client usually does not know it is there.

What do teams use it for?

• TLS termination: one place to manage certificates and protocol settings.
• Load balancing: spread requests over several instances and stop sending to unhealthy ones.
• Caching: serve repeated static content without touching the application.
• Routing: send paths such as one for the API and another for the web app to different services.
• Filtering: block malformed requests, enforce size limits and rate limits, and sometimes run a web application firewall.
• Hiding: keep backend addresses and software details away from the internet.

What are the risks?

A reverse proxy is also a single point that sees everything and a single point of failure. A misconfiguration can expose internal admin pages, since the backend may trust whatever the proxy forwards. Backends often trust headers that the proxy sets, such as the original client address. If a client can send those headers directly, they can be forged. The proxy should overwrite them, not append to them.

And the two layers can disagree on how to read a request. Differences in parsing between a proxy and a backend are a known source of request smuggling bugs. Keep both layers patched and use one consistent HTTP version where you can.

A constructed example

A company runs a customer app on three servers and an internal admin tool on a fourth. They place a reverse proxy in front. It terminates TLS, routes the public path to the three app servers in rotation, and has no route at all to the admin tool from the internet. When a new app release fails its health check on one server, the proxy stops sending traffic there. Later a developer adds a debug route to the app. Because routing is allowlisted at the proxy, the route is not reachable from outside until someone deliberately publishes it.

How to check or apply this

1. Define routes as an allowlist, and default to denying unknown paths.
2. Terminate TLS with modern settings, and consider encrypting the hop to the backend too.
3. Have the proxy set trusted headers itself, and strip client-supplied versions.
4. Set request size, time and rate limits.
5. Keep admin interfaces off the public proxy.
6. Add health checks and test failover.
7. Log requests at the proxy, and keep those logs protected.
8. Patch the proxy as you would any internet-facing component.

Quick check

Sources

• RFC 9110, HTTP Semantics
• NIST glossary, proxy server
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy

Last reviewed: 18 October 2026.