Reverse Proxies: Architecture & Use Cases

A reverse proxy is a server that sits in front of one or more backend servers, intercepting and forwarding client requests on behalf of those servers. Unlike a forward proxy that acts on behalf of clients, a reverse proxy acts on behalf of servers — clients don’t even know they’re communicating with a proxy. Understanding reverse proxies is crucial because they power most of the internet’s largest websites and services, from Netflix to Amazon.

This guide covers reverse proxy architecture, implementation, and real-world applications in detail.

Forward Proxy vs Reverse Proxy

The distinction is fundamental:

FORWARD PROXY (acts for clients):
Client → Forward Proxy → Internet → Server
↑ Client knows about this

REVERSE PROXY (acts for servers):
Client → Internet → Reverse Proxy → Backend Servers
↑ Client doesn't know about this

How Reverse Proxies Work

Basic Request Flow

1. Client sends request to example.com (resolves to reverse proxy IP)

Reverse proxy receives the request
Reverse proxy evaluates:

Which backend server should handle this?
Is there a cached response?
Should this request be blocked?
Reverse proxy forwards to selected backend server
Backend server processes and responds
Reverse proxy relays response to client

DNS Configuration

The reverse proxy works because the domain’s DNS points to the proxy, not the backend:

example.com → A Record → 203.0.113.10 (Reverse Proxy IP)

Backend servers (hidden from public):

10.0.0.1:8080 (App Server 1)
10.0.0.2:8080 (App Server 2)
10.0.0.3:8080 (App Server 3)

Core Functions of Reverse Proxies

1. Load Balancing

Distribute incoming traffic across multiple backend servers:

                    Reverse Proxy
/      |      \
Server1  Server2  Server3
(33%)    (33%)    (33%)

Load Balancing Algorithms:

2. SSL/TLS Termination

Handle encryption/decryption at the proxy level, offloading CPU-intensive TLS processing from backend servers:

Client ←→ [HTTPS/TLS] ←→ Reverse Proxy ←→ [HTTP] ←→ Backend
(handles SSL)      (unencrypted, fast)

3. Caching

Cache frequently requested content to reduce backend load:

Request 1: GET /api/products
→ Proxy forwards to backend, caches response (TTL: 60s)

Request 2: GET /api/products (within 60s)
→ Proxy returns cached response (no backend hit)
→ Response time: 1ms vs 200ms

4. Security & DDoS Protection

• Hide backend infrastructure — Attackers can’t directly target your servers
• Rate limiting — Throttle excessive requests per IP
• WAF (Web Application Firewall) — Filter malicious requests
• DDoS mitigation — Absorb volumetric attacks

5. Compression

Compress responses before sending to clients:

Backend response: 500KB HTML
After gzip compression: 80KB
Bandwidth saved: 84%

6. URL Rewriting

Route requests to different backends based on URL path:

/api/*     → API Server (10.0.0.1:3000)
/static/*  → CDN/Static Server (10.0.0.2:80)
/admin/*   → Admin Server (10.0.0.3:8080)
/*         → Main App Server (10.0.0.4:8080)

Implementation Examples

Nginx Reverse Proxy

# /etc/nginx/conf.d/reverse-proxy.conf

upstream backend_servers {
least_conn;
server 10.0.0.1:8080 weight=3;
server 10.0.0.2:8080 weight=2;
server 10.0.0.3:8080 weight=1;
}

server {
listen 443 ssl;
server_name example.com;

ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;

# Caching
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m;

location / {
proxy_pass http://backend_servers;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Caching
proxy_cache my_cache;
proxy_cache_valid 200 60m;
proxy_cache_valid 404 1m;
}

location /static/ {
proxy_pass http://10.0.0.2:80;
proxy_cache my_cache;
proxy_cache_valid 200 24h;
}

# Rate limiting
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
limit_req zone=api burst=20;
proxy_pass http://10.0.0.1:3000;
}
}

HAProxy Configuration

# /etc/haproxy/haproxy.cfg

frontend http_front
bind *:80
bind *:443 ssl crt /etc/ssl/certs/example.pem
redirect scheme https if !{ ssl_fc }
default_backend http_back

backend http_back
balance roundrobin
option httpchk GET /health
server server1 10.0.0.1:8080 check weight 3
server server2 10.0.0.2:8080 check weight 2
server server3 10.0.0.3:8080 check weight 1 backup

Caddy (Simplest Configuration)

# Caddyfile
example.com {
reverse_proxy 10.0.0.1:8080 10.0.0.2:8080 {
lb_policy least_conn
health_uri /health
health_interval 10s
}
}

Traefik (Docker-Native)

# docker-compose.yml
version: '3'
services:
traefik:
image: traefik:v2.10
command:

"--providers.docker=true"
"--entrypoints.web.address=:80"
"--entrypoints.websecure.address=:443"

ports:

"80:80"
"443:443"

volumes:

/var/run/docker.sock:/var/run/docker.sock


app:
image: myapp:latest
labels:

"traefik.http.routers.app.rule=Host(example.com)"
"traefik.http.services.app.loadbalancer.server.port=8080"

deploy:
replicas: 3

Real-World Reverse Proxy Services

CDN Providers as Reverse Proxies

API Gateways

API gateways are specialized reverse proxies for API traffic:

• Kong — Open-source API gateway with plugin ecosystem
• AWS API Gateway — Managed service for REST and WebSocket APIs
• NGINX Plus — Commercial version with API management features

Performance Optimization

Connection Pooling

Without reverse proxy:
Client 1 → New TCP connection → Backend
Client 2 → New TCP connection → Backend
Client 3 → New TCP connection → Backend

With reverse proxy (connection pooling):
Client 1 ─┐
Client 2 ──┼→ Reverse Proxy → Persistent connection pool → Backend
Client 3 ─┘   (multiplexes requests over few connections)

HTTP/2 and HTTP/3 Termination

Client ←→ [HTTP/2 or HTTP/3] ←→ Reverse Proxy ←→ [HTTP/1.1] ←→ Backend
(modern protocol)                      (legacy backend)

The reverse proxy can speak modern protocols to clients while maintaining compatibility with older backends.

Reverse Proxies and Web Scraping

Websites use reverse proxies to block scrapers:

• Rate limiting at the proxy layer
• IP blocking and geo-restrictions
• Bot detection integration (Cloudflare, Akamai)
• CAPTCHA injection for suspicious traffic

To scrape sites behind reverse proxies, you need quality forward proxies (residential or mobile) to distribute your requests. [link to: what-is-a-residential-proxy-detailed]

Frequently Asked Questions

What’s the difference between a reverse proxy and a load balancer?

A load balancer is one function of a reverse proxy. Reverse proxies do load balancing plus caching, SSL termination, compression, security filtering, and URL rewriting. A dedicated load balancer (like AWS ELB) focuses primarily on distributing traffic.

Do I need a reverse proxy for a small website?

For very small sites (single server, low traffic), a reverse proxy adds unnecessary complexity. However, even small sites benefit from using Cloudflare (free tier) as a reverse proxy for DDoS protection, SSL, and caching.

Can a reverse proxy improve my website’s SEO?

Indirectly, yes. Reverse proxies improve page load speed (through caching and compression), enable HTTPS (ranking factor), and improve uptime (through load balancing) — all factors that influence search rankings.

Is Cloudflare a reverse proxy?

Yes, Cloudflare functions as a reverse proxy. When you add your domain to Cloudflare, DNS points to Cloudflare’s servers, which proxy all requests to your origin server. Cloudflare adds caching, DDoS protection, WAF, and performance optimization as a reverse proxy layer.

Can reverse proxies handle WebSocket connections?

Yes, modern reverse proxies (Nginx 1.3+, HAProxy 1.6+, Caddy, Traefik) support WebSocket proxying. The proxy upgrades the HTTP connection to a WebSocket connection and maintains the persistent bidirectional tunnel.