A reverse proxy is a server that sits between client browsers and one or more backend web servers, receiving incoming requests from clients, forwarding them to the appropriate backend server, and returning the backend’s response to the client. From the client’s perspective the reverse proxy is the web server, the client connects to the reverse proxy’s IP address and receives responses directly from it. The backend servers are hidden behind the reverse proxy, clients never connect to them directly and may not know they exist.

The word reverse distinguishes this configuration from a forward proxy. A forward proxy sits in front of clients, acting on behalf of users to access the internet. A corporate network proxy that routes all employee internet traffic through a single server is a forward proxy. A reverse proxy is the mirror image, it sits in front of servers, acting on behalf of servers to receive and process client requests.

Reverse proxies are one of the most widely deployed components of web infrastructure, used for load balancing across multiple backend servers, SSL termination, caching, compression, security filtering, and critically for redirect management. Nginx, Apache, HAProxy, and Caddy are common reverse proxy implementations used in web infrastructure. Cloud providers and CDN platforms, Cloudflare, AWS CloudFront, and others, operate as reverse proxies at global scale.

Understanding reverse proxies is important for redirect management because redirects are frequently implemented at the reverse proxy layer, before requests reach application code. A redirect rule configured in Nginx or Apache executes in the reverse proxy, returning redirect responses directly without the request needing to reach the application server.

How reverse proxies work

The reverse proxy sits in the request-response path, intercepting every incoming request before it reaches the backend and every outgoing response before it reaches the client.

Request flow: a client browser sends an HTTP request to what it believes is the web server, the reverse proxy’s IP address. The reverse proxy receives the request, examines it, checking the Host header, path, method, and other attributes, and determines how to handle it. For requests that should be forwarded to a backend the reverse proxy opens a connection to the appropriate backend server and forwards the request. The backend processes the request and returns a response to the reverse proxy. The reverse proxy returns the response to the client, often modifying headers, caching the response, or performing other transformations in the process.

Connection handling: the client maintains a connection with the reverse proxy, not with the backend server. The reverse proxy maintains separate connections with backend servers. This connection separation allows the reverse proxy to reuse backend connections across multiple client requests, connection pooling, reducing the overhead of establishing new backend connections for every client request.

Host header forwarding: the reverse proxy typically forwards the original Host header from the client request to the backend, or sets an X-Forwarded-Host header. This allows backend applications to know the original domain the client was requesting, important for generating correct absolute URLs in responses and for applications serving multiple domains. Without Host header forwarding backend applications cannot distinguish which domain a request was intended for.

IP address forwarding: since the backend server receives connections from the reverse proxy rather than from the client the backend sees the reverse proxy’s IP address as the client IP. The reverse proxy typically adds an X-Forwarded-For header containing the original client IP address, allowing backend applications to log and process the real client IP rather than the reverse proxy IP. This header is important for geolocation, rate limiting, and security applications that need the actual client IP.

Reverse proxy use cases

Reverse proxies serve multiple purposes in web infrastructure, often handling several responsibilities simultaneously.

Load balancing: distributing incoming requests across multiple backend server instances to balance load and improve availability. The reverse proxy maintains a pool of backend servers and routes each incoming request to an available server according to a distribution algorithm, round-robin distributes requests sequentially across servers, least connections routes to the server with the fewest active connections, IP hash routes the same client consistently to the same backend.

Load balancing enables horizontal scaling, adding more backend servers increases capacity proportionally. When one backend server fails the reverse proxy detects the failure through health checks and stops routing requests to the failed server, automatically redirecting traffic to healthy servers. Load balancing is one of the primary reasons for reverse proxy deployment in production infrastructure.

SSL termination: handling the TLS handshake and encryption at the reverse proxy rather than at the backend server. The client establishes a secure HTTPS connection with the reverse proxy, the TLS handshake, certificate verification, and encryption processing all happen at the reverse proxy. The connection between the reverse proxy and backend servers may use plain HTTP, on a private network where encryption is less critical, or a separate HTTPS connection.

SSL termination at the reverse proxy centralises certificate management, SSL certificates are installed and managed on the reverse proxy rather than on each individual backend server. This simplification is significant at scale, managing certificates across dozens of backend servers is substantially more complex than managing them on a single reverse proxy.

Caching: storing responses from backend servers and serving cached versions for subsequent identical requests. A reverse proxy cache reduces backend load by serving cached responses without forwarding requests to the backend. Response caching is particularly effective for content that is requested frequently but changes infrequently, static assets, HTML pages with long cache durations, API responses with stable data.

Compression: compressing responses before sending them to clients. The reverse proxy applies gzip or Brotli compression to response bodies, reducing the data size that must be transmitted over the network. Compression at the reverse proxy offloads the compression processing from backend servers and ensures consistent compression regardless of whether individual backend applications implement compression.

Security filtering: inspecting incoming requests and blocking malicious traffic before it reaches backend servers. Reverse proxies implement web application firewall, WAF, functionality, rate limiting, IP blocking, and bot detection at the proxy layer. Security filtering at the reverse proxy protects all backend servers uniformly, rather than requiring security filtering implementation in each backend application.

Reverse proxies and redirects

Reverse proxies are a primary implementation point for redirect rules: executing redirect logic at the proxy layer before requests reach application servers.

Redirect rules in reverse proxy configuration: Nginx, Apache, Caddy, and other reverse proxies provide configuration directives for implementing redirects directly in the proxy configuration. These redirect rules execute at the proxy layer, returning redirect responses without the request reaching the backend application. This proxy-layer execution is fast, no application server processing, no database queries, no dynamic code execution, the redirect response is generated directly from the proxy’s configuration.

Nginx redirect example, a 301 permanent redirect from an old domain to a new domain:

server {
    listen 80 443 ssl;
    server_name old-domain.com;
    return 301 https://new-domain

server {
    listen 80 443 ssl;
    server_name old-domain.com;
    return 301 https://new-domain

server {
    listen 80 443 ssl;
    server_name old-domain.com;
    return 301 https://new-domain

Apache redirect example, a redirect in.htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

Caddy redirect example, automatic HTTPS with redirect:

old-domain.com {
    redir https://new-domain.com{uri} 301
}

old-domain.com {
    redir https://new-domain.com{uri} 301
}

old-domain.com {
    redir https://new-domain.com{uri} 301
}

HTTP to HTTPS upgrade at the proxy: the most universal redirect implemented at the reverse proxy layer. Every HTTP request is redirected to HTTPS, the reverse proxy returns a 301 redirect for all HTTP requests without forwarding them to the backend. HTTPS requests are forwarded normally, the backend never receives HTTP requests.

Path-based redirects at the proxy: the reverse proxy can implement path-based redirect rules, redirecting specific URL paths or path patterns to new destinations. Legacy URL structures, changed page paths, and retired sections can be handled at the proxy layer, the backend application only needs to handle the current URL structure while legacy paths are redirected by the proxy.

Wildcard redirects in proxy configuration: reverse proxy configuration supports pattern-based redirect rules using regular expressions. A pattern matching all URLs under an old path prefix redirects to equivalent paths under a new prefix:

rewrite ^/old-blog/(.*)$ /blog/$1 permanent

rewrite ^/old-blog/(.*)$ /blog/$1 permanent

rewrite ^/old-blog/(.*)$ /blog/$1 permanent

This rule captures the path component after /old-blog/ and redirects to the same path under /blog/: handling the entire blog URL structure change with one rule.

Reverse proxy vs application-level redirects

Redirect logic can be implemented at multiple layers, the reverse proxy, the application framework, or a dedicated redirect management platform. Each layer has different characteristics.

Reverse proxy redirect advantages: proxy-level redirects execute before application code runs, faster response times, no application server load for redirected requests. Configuration changes require proxy configuration updates and reloads, not application deployments. Proxy configuration is independent of the application’s programming language and framework.

Reverse proxy redirect limitations: proxy configuration requires server access and technical expertise. Configuration changes may require service reloads or restarts, with potential impact on in-flight requests. Complex redirect logic, database lookups, conditional logic based on request attributes, is difficult to implement in proxy configuration languages. Managing large numbers of individual redirect rules in proxy configuration files becomes unwieldy.

Application-level redirect advantages: application code can implement complex redirect logic, database lookups for dynamic redirects, conditional logic based on user state, redirect rules stored in databases rather than configuration files. Non-technical team members can manage redirects through application admin interfaces without server access.

Application-level redirect limitations: every redirect request reaches the application server, consuming application server resources even for simple redirects. Application server processing is slower than proxy-level processing for simple static redirects. Application deployments are required to update redirect logic embedded in application code.

Dedicated redirect management platform advantages: platforms like Redirect Supply provide the best of both approaches, redirect rules managed through a non-technical interface, no server access required, executed at the edge network layer, fast performance without application server involvement. Redirect rules stored in a managed database with bulk import, pattern matching, and monitoring. SSL certificates provisioned automatically for all connected domains.

Nginx as a reverse proxy

Nginx is one of the most widely deployed reverse proxy implementations, used both as a standalone reverse proxy and as a web server with reverse proxy capabilities.

Basic reverse proxy configuration: forwarding requests to a backend application server:

server {
    listen 443 ssl;
    server_name example.com;
    
    location / {
        proxy_pass http://backend-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto

server {
    listen 443 ssl;
    server_name example.com;
    
    location / {
        proxy_pass http://backend-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto

server {
    listen 443 ssl;
    server_name example.com;
    
    location / {
        proxy_pass http://backend-server:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto

Upstream load balancing: distributing requests across multiple backends:

upstream backend_pool {
    server backend-1:8080;
    server backend-2:8080;
    server backend-3:8080;
}

server {
    location / {
        proxy_pass http

upstream backend_pool {
    server backend-1:8080;
    server backend-2:8080;
    server backend-3:8080;
}

server {
    location / {
        proxy_pass http

upstream backend_pool {
    server backend-1:8080;
    server backend-2:8080;
    server backend-3:8080;
}

server {
    location / {
        proxy_pass http

SSL termination with redirect: redirecting HTTP to HTTPS and terminating SSL:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    
    location / {
        proxy_pass http://backend-server

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    
    location / {
        proxy_pass http://backend-server

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    
    location / {
        proxy_pass http://backend-server

Reverse proxies and security

Reverse proxies implement security measures that protect backend infrastructure from exposure and attack.

Backend IP address hiding: backend servers receive connections only from the reverse proxy, their IP addresses are not exposed to the public internet. An attacker who discovers a vulnerability in the web application cannot directly attack the backend server if its IP address is unknown. The reverse proxy is the only publicly exposed infrastructure component.

Request filtering: the reverse proxy can inspect and filter incoming requests before they reach the backend, blocking requests with malicious headers, suspicious patterns, or known attack signatures. Rate limiting at the proxy layer, limiting requests per IP per time period, prevents brute force and scraping attacks from overwhelming the backend.

DDoS mitigation: reverse proxies, particularly those backed by CDN infrastructure, can absorb and filter DDoS attack traffic at the proxy layer. Volumetric attacks that would overwhelm a backend server are handled at the proxy before reaching the backend.