Other meanings of Reverse proxy
NETWORKING
A reverse proxy is a network server that forwards client requests to one or more backend servers. It presents a public endpoint while concealing, selecting, and often protecting the servers that provide the requested application or resource.
A reverse proxy separates the public network endpoint from the servers that perform application work. A client connects to the proxy, which evaluates the request and forwards it to a selected backend server; the response then travels back through the proxy. This differs from a forward proxy, which represents clients to external servers. The arrangement is common in HTTP deployments, where routing may depend on a hostname, URL path, headers, cookies, or other request properties.1
The backend can remain on a private network, while the proxy owns the public DNS name and connection to the client. A single proxy can therefore expose several applications, and several proxy instances can provide redundancy. The proxy may preserve or add metadata such as the original client address through standardized forwarding headers, but applications must be configured to trust those headers only from known proxy infrastructure.
Reverse proxies combine request routing with traffic-management functions. They commonly terminate TLS, translate between public and internal addresses, balance requests across healthy backends, compress responses, cache selected content, and enforce request-size or timeout limits.2 These functions reduce repeated work by application servers and allow administrators to change backend membership without changing the public endpoint.
Deployments range from a dedicated appliance to software such as NGINX, HAProxy, or the Apache HTTP Server. In container platforms, an ingress controller often performs the same front-door role for services inside a cluster. Proxying is not automatically load balancing: a configuration may forward every request to one backend, use weighted distribution, or apply session affinity. Health checks and careful connection limits are needed to prevent an unhealthy or overloaded backend from receiving traffic.
A reverse proxy must preserve the semantics of the protocol it carries while deciding which traffic to accept. For HTTP/1.1, HTTP/2, and HTTP/3, this includes correct handling of hostnames, paths, methods, status codes, connection reuse, and forwarded scheme information; the HTTP specifications define the message and routing semantics that intermediaries must respect.3 WebSocket and streaming responses require special upgrade or buffering settings.
The proxy is also a security boundary, but not a complete security solution. Operators commonly place authentication, rate limiting, access controls, and web-application filtering at this layer. Misconfigured routing can expose administrative services, mishandle encoded paths, or let attackers exploit trust in client-supplied forwarding headers. A proxy that can fetch arbitrary destinations may also create a server-side request forgery risk, so backend destinations should be constrained and validated.4
Several less visible proxy behaviors can determine whether an application works correctly. A proxy may buffer an upload or response, alter the apparent scheme from HTTPS to HTTP, rewrite redirects, or impose idle timeouts that interrupt long-lived connections. Cache behavior is governed by HTTP response directives and intermediary rules rather than by the mere presence of a proxy; shared caches must account for authorization, privacy, and validation headers.5
Reverse proxies are also used beyond ordinary websites. They front APIs, mail or database gateways, internal dashboards, object stores, and geographically distributed services, and they can provide a controlled bridge between incompatible network zones. In large systems, several proxy layers may exist: a content delivery network can precede a regional proxy, which then routes to service-specific gateways. Each added layer complicates observability, so consistent request identifiers, timing data, and access logs are essential for tracing a response to its origin.
Terminology follows standard HTTP and intermediary-networking usage; individual products may implement additional proxy features or use different configuration names.
Help improve the encyclopedia. Reports go straight to the site manager.