What Is a Reverse Proxy?

Reverse Proxy Explainer

A reverse proxy is a server that clients contact instead of contacting an application server directly. It accepts a request for the public service, selects an upstream server, forwards an appropriate version of the request, receives the result, and returns that result to the client. The browser may never learn which backend handled the work. The word reverse distinguishes this role from a forward proxy, which represents clients as they access outside destinations. A reverse proxy represents servers to the outside world.

The proxy can terminate a client’s TLS connection. It presents the site certificate, negotiates encryption, and decrypts the HTTP request so it can apply routing or security rules. The connection from proxy to upstream can be another encrypted link or a protected internal connection. Central termination simplifies certificate renewal and gives older applications modern protocol support, but it concentrates sensitive keys and plaintext at the proxy. Access controls, patching, and secure key storage are therefore essential.

Routing can use the requested hostname, path, headers, method, or other application information. Several websites may share one address, or one site may direct image, API, and authentication paths to different services. The proxy rewrites destination details and adds forwarding headers so the upstream can understand the original client, scheme, and host. Applications must trust those headers only from known proxies; accepting a forged client address from the open Internet can bypass logging or security logic.

Reverse proxies also provide shared functions. They can compress responses, cache reusable objects, enforce request-size and rate limits, authenticate users, filter known attack patterns, and normalize protocol details. Connection pooling reduces repeated setup with upstream servers. Buffering protects a slow client from tying up an application worker, but it consumes memory or disk and can delay streaming. Timeouts and body limits must match legitimate workloads without allowing stalled connections to exhaust resources.

When several upstreams provide the same service, the reverse proxy can load-balance among them and check their health. This overlaps with the role of a load balancer; many products do both. A proxy may retry a failed request on another server, but retries are safe only when the operation can be repeated without unintended effects. Replaying a payment or data-changing request can be dangerous. Good configurations distinguish connection failures from application errors and respect idempotency.

The proxy creates an additional failure and trust boundary. If it is unavailable, misconfigured, or overloaded, every protected backend may appear down. Redundant instances, configuration testing, gradual rollout, metrics, and meaningful error pages reduce that risk. Logs at both proxy and application are needed to trace a request. WebSocket, streaming, large uploads, and long-lived API calls require specific timeout and buffering behavior that an ordinary page-serving configuration may not provide.

A reverse proxy is therefore a controlled front door. It hides upstream topology, consolidates encryption and policy, routes requests, and can cache or balance traffic before application code runs. It does not inherently make an application secure or fast; an incorrect rule can expose an internal service or cache private content. Its value comes from enforcing one carefully managed boundary between unpredictable clients and a changing collection of backend servers.