A reverse proxy is a web server that accepts public requests and forwards them to an internal server. Clients see one public address. The proxy chooses a backend and returns its response.
- Public entry
The internet client reaches the proxy’s public address.
- Proxy work
The proxy can terminate TLS, apply access controls, compress, cache, or serve static files as configured.
- Internal server
Forward the request to a private web server and return its response.
A reverse proxy forwards requests and returns responses under explicit configuration.
How to read this model
A public entry fixture before a private worker enclosure. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from Wikipedia.
A reverse proxy can provide:
- Security controls such as hiding backend addresses, denying IPs, and limiting connections per client.
- TLS termination, so backend nodes do not each manage an X.509 certificate.
- Compression of responses.
- Caching for cacheable responses.
- Direct delivery of static HTML, CSS, JavaScript, images, and videos.
- A stable public interface while internal servers scale or change.
Reverse proxy and load balancer
A load balancer distributes work across multiple servers that perform the same function. A reverse proxy can be useful with one backend because it still provides TLS termination, caching, compression, and a public-to-private seam. NGINX and HAProxy can act as both a layer 7 reverse proxy and a load balancer.
The distinction is about the role you need. When the primary problem is choosing among healthy instances, use load-balancing behavior. When the primary problem is mediating all public traffic, a reverse proxy may be enough.
Costs and failure modes
The proxy adds another process, configuration, and place where timeouts can be wrong. A single proxy is a single point of failure. Run multiple proxies and test their failover if the proxy is part of the availability target.
See the request lifecycle for how a request moves through backend modules and security for controls at each layer.