Table of Contents
Introduction
A reverse proxy is a server that sits in front of one or more backend servers and receives client requests on their behalf. Instead of clients talking directly to your application or web servers, they talk to the reverse proxy, and the proxy forwards, modifies, or filters those requests and responses.
This chapter focuses on what is specific to reverse proxies in a Linux server context, not on the details of individual web server software, which are covered separately.
Forward proxy vs reverse proxy
A useful way to understand reverse proxies is to compare them with forward proxies.
A forward proxy is used by clients to access the internet. The client knows about the proxy and is configured to send all traffic to it. The proxy then fetches data from servers on the internet and returns it to the client. This is common in corporate networks and content filtering systems.
A reverse proxy is used by servers to control and manage how clients reach them. The client typically does not know there is a reverse proxy. It connects to what looks like the final server. The reverse proxy then decides which real server or service to talk to internally.
In short, a forward proxy represents clients, while a reverse proxy represents servers.
Basic request flow
In a basic setup, a client sends an HTTP or HTTPS request to a public IP address associated with your site. That IP resolves to the reverse proxy, which accepts the request on ports like 80 or 443. The reverse proxy then decides what to do based on rules you define, such as domain name, URL path, or HTTP headers.
The proxy opens its own connection to a backend server, often on a private network or localhost, forwards the request, waits for the response, possibly modifies it, and then sends the final response to the client.
From the client’s perspective, everything came from the reverse proxy host. The backend servers remain hidden behind it.
Core responsibilities of a reverse proxy
A reverse proxy can perform several distinct roles for HTTP and HTTPS traffic. Not every deployment uses all of these, but understanding them helps you design robust architectures.
Central entry point
The reverse proxy acts as a single entry point into your infrastructure. Instead of exposing multiple application servers directly to the internet, you expose only the proxy. This simplifies firewall rules and public DNS. Internally, you can route to many backends that are reachable only from the proxy.
This centralization is especially useful when you have multiple services such as an API, a web app, and a static site. The reverse proxy can route to all of them while presenting a single public domain or a small set of domains.
Request routing
Reverse proxies can route incoming requests to different backend servers or applications. This is often based on:
Domain name using HTTP Host or :authority for HTTP/2. Different virtual hosts represent different sites or services.
URL path. For example, /api to an API server and / to a frontend server.
Port or protocol. For example, forwarding HTTP to some backends and WebSocket or HTTP/2 streams to others.
This URL and host based routing is also called application layer routing, because it happens at the HTTP level rather than by IP alone.
Load balancing
A reverse proxy can distribute incoming requests across a pool of backend servers. This process is known as load balancing. By spreading requests, you reduce the load on any single backend and can horizontally scale your application.
Common load balancing methods include simple round robin, where requests are sent to each backend in turn, and least connections, where the backend with the fewest active connections gets the next request. Some setups use weighted methods to send more traffic to more powerful servers.
The reverse proxy keeps track of backend health by performing health checks, such as HTTP requests to a particular path or TCP connection tests. If a backend stops responding correctly, the proxy can temporarily remove it from the pool. When it recovers, it can be added back automatically.
SSL/TLS termination
A very common use of reverse proxies is TLS termination. The proxy accepts HTTPS connections from clients, performs the cryptographic work, and then forwards unencrypted HTTP to backends on a trusted network. The backends can listen on plain HTTP, which simplifies their configuration.
In this model, the TLS certificates and keys live on the reverse proxy. It is responsible for renewing certificates, supporting modern cipher suites, and enforcing secure protocols such as TLS 1.2 or TLS 1.3.
TLS termination can also be combined with TLS re encryption. The proxy decrypts the client connection, inspects and routes the request, and then opens a separate encrypted connection to the backend using another certificate. This is useful when the network between the proxy and backends is not entirely trusted.
When a reverse proxy terminates TLS and forwards plain HTTP to backends, all traffic between the proxy and backends must be considered sensitive. Protect this network segment with firewalls, segmentation, and strict access controls.
Centralized authentication and access control
Because all traffic passes through the reverse proxy, it can become a central enforcement point for authentication and authorization. Instead of implementing complex access control in every application, you can use the proxy to handle some tasks such as:
HTTP Basic or digest authentication.
Token validation for session cookies or headers.
Integration with external identity providers using single sign on technologies.
IP allowlists or deny lists.
Rate limits for specific authenticated identities.
The proxy may add headers to the forwarded request, indicating the authenticated user or roles, which backends can read to make fine grained decisions.
Caching
A reverse proxy can cache frequently requested responses. For static assets, or even some dynamic pages that do not change per user, the proxy can store the generated response in its cache. Subsequent requests can be served directly from the cache without contacting the backend.
This reduces latency for clients and dramatically decreases load on application servers. Effective caching requires careful control of cache keys, expiry times, and invalidation strategies. Cache behavior is influenced by HTTP headers such as Cache Control, Expires, and ETag.
Compression and optimization
Reverse proxies can compress responses using algorithms such as gzip or Brotli before sending them to clients. The client indicates supported encodings in the Accept Encoding header, and the proxy can transform backend responses accordingly.
They can also handle tasks such as:
Adding or removing HTTP headers.
Minifying some content types.
Normalizing or rewriting URLs.
These capabilities improve performance and security without changing the application itself.
Security gateway
Since the reverse proxy is the publicly exposed component, it is a natural place to implement some security controls. These can include:
Basic filtering of malformed requests.
Limitations on request size and number of headers.
Request rate limits per IP or subnet.
Integration with a web application firewall engine to detect common attack patterns such as SQL injection or cross site scripting probes.
Hiding details about backend servers by removing or rewriting server headers and error messages.
While a reverse proxy is not a complete security solution, it reduces the attack surface of individual backends and gives you a single place to enforce many policies.
Typical deployment topologies
Reverse proxies can be used in different positions depending on the complexity of your environment.
Single proxy in front of a single backend
The simplest case uses one reverse proxy in front of a single web server or application. This can still be useful if you want the proxy to manage TLS, compression, or caching while the backend focuses on generating content.
In this model, the reverse proxy can also offload some features that your application server is not good at, such as handling many concurrent connections efficiently.
Single proxy in front of multiple backends
More common in production is a single proxy that fronts multiple backends. These may be different services, such as a frontend, an API, and a static file server, or multiple instances of the same service to scale out.
Routing rules determine which backend receives each request. Each backend might be hosted on its own VM, container, or even another physical server, often on a private network segment.
Layered proxies and gateways
In larger systems, you might find multiple layers. For example, an external load balancer or reverse proxy terminates TLS and routes traffic to a second tier of internal proxies or application gateways, which then talk to microservices.
At each layer, different responsibilities can be handled. One layer could focus on public TLS and global routing, another on authentication and internal service to service policies.
Reverse proxy before application servers
Common application servers, such as language specific runtime servers, often listen on higher ports and are not directly hardened for internet exposure. Instead of exposing them, you place the reverse proxy in front and route requests from the proxy to the app servers over HTTP on ports like 8080 or 3000.
This approach also allows you to run multiple different applications on the same host without port conflicts, since the reverse proxy can map distinct domains or paths to separate backends.
URL and header rewriting
Reverse proxies often modify parts of the request or response to make multiple systems integrate smoothly.
For incoming requests, the proxy might:
Rewrite URL paths before forwarding them, for example stripping a prefix so the backend sees a simpler path.
Add headers such as X Forwarded For, X Forwarded Host, and X Forwarded Proto to convey original client information.
For outgoing responses, the proxy might:
Rewrite Location headers so that redirects point to public URLs instead of internal ones.
Adjust Set Cookie attributes to match the desired domain and path.
Change Content Location or links in some HTML responses if required.
Backends that are deployed behind a reverse proxy must be aware of proxy added headers such as X Forwarded For and X Forwarded Proto if they perform logging, IP based logic, or generate absolute URLs. Misinterpreting these headers can cause security or correctness problems.
Handling client IP and logging
Because the reverse proxy terminates client connections, from the backend perspective all traffic appears to originate from the proxy IP. To preserve real client addresses, proxies insert specific headers.
The most traditional header is X Forwarded For. It usually contains a comma separated list of IP addresses, where the leftmost is the original client IP, and subsequent entries represent intermediate proxies that forwarded the request.
More standardized approaches use the Forwarded header or proxy protocol at the TCP level. Application and logging code needs to be configured to trust and interpret these values correctly, but only from trusted proxies.
Reverse proxies themselves also maintain their own access logs. These logs should be carefully configured to capture essential details such as timestamps, requested URIs, response codes, response times, and client IPs. Centralizing logging at the proxy gives a high level picture of inbound traffic.
Session persistence
In load balanced scenarios, some applications require that a user’s repeated requests reach the same backend instance. This behavior is called session persistence or sticky sessions.
Reverse proxies can implement stickiness using:
Cookies. The proxy sets a cookie that encodes which backend was chosen, and then sends future requests from that client to the same server.
Source IP hashing. The proxy maps the client IP to a backend in a deterministic way.
Application headers. The proxy may read or set custom headers to maintain the mapping.
This can be convenient for stateful applications, but it has trade offs in terms of balancing efficiency and failover behavior if a chosen backend goes down.
Timeouts and connection limits
Reverse proxies manage thousands of client and backend connections. Correctly configured timeouts and limits are crucial to prevent resource exhaustion and denial of service.
Common settings include:
Maximum time the proxy waits for a client to send the full request.
Maximum time to establish a connection to a backend.
Idle connection timeout between proxy and backend.
Limits on the number of concurrent connections per client IP or site.
If these values are too low, legitimate long running requests can be cut off. If too high, slow or stuck clients can tie up resources. Balancing these values is a key operational concern in reverse proxy design.
Reverse proxies with HTTP/2 and WebSockets
Modern applications often rely on HTTP/2 features such as multiplexing and header compression, or use WebSockets for real time communication. A reverse proxy can be used as a protocol translation point.
For example, the proxy may accept HTTP/2 from clients but communicate with backends using HTTP/1.1. The application servers do not need to understand HTTP/2, which simplifies them.
With WebSockets, the proxy must support the upgrade mechanism and keep long lived connections open to backends. Connection and resource management become more sensitive, and any connection limits on the proxy apply directly to how many concurrent users you can support.
High availability for the reverse proxy itself
Because the reverse proxy is the entry point, it becomes a critical component. If it fails, your entire site can become unreachable even if all backends are healthy.
To avoid this single point of failure, production environments deploy multiple reverse proxies behind a higher level load balancer or with failover techniques such as:
Multiple instances with a shared virtual IP managed by clustering tools.
DNS level balancing across several proxy IPs.
Anycast or cloud load balancing services that distribute traffic to multiple proxy nodes.
Configuration and state, such as TLS certificates and routing rules, must be kept synchronized across these proxy instances.
Reverse proxy in microservices and service meshes
In microservice architectures, reverse proxies are frequently used as API gateways. The gateway is the single public endpoint for many internal services. It can perform:
Version based routing.
Request transformation.
Centralized rate limiting and authentication.
Some environments extend this idea further into a service mesh, where sidecar proxies handle communication between services internally. Although that is a separate topic, the conceptual foundation is the same: proxies manage traffic, while services focus on business logic.
Summary
Reverse proxies are central tools in modern Linux based web infrastructure. They receive client requests, route them to appropriate backends, balance load, terminate TLS, cache and optimize responses, and enforce a range of security and access policies. Understanding these concepts is essential before you configure specific software as a reverse proxy or integrate it into high availability and large scale designs.