Reverse Proxy

How a reverse proxy works

Client                  Reverse Proxy                  Backend(s)
  │ HTTPS request          │                              │
  │──────────────────────► │                              │
  │                        │ Decrypts, inspects,          │
  │                        │ load balances, etc.          │
  │                        │ HTTP request                 │
  │                        │ ────────────────────────────►│
  │                        │                              │ Processes
  │                        │ ◄────────────────────────────│ Response
  │                        │ Caches, compresses,          │
  │                        │ re-encrypts                  │
  │ HTTPS response         │                              │
  │◄──────────────────────│                              │

The client only sees the reverse proxy. The proxy holds the TLS certificate for the public-facing domain, accepts HTTPS connections, and decides what to do with each request. Backend servers may be on a private network, in different data centers, in containers, or auto-scaled instances behind a load balancer — invisible to the client.

What a reverse proxy actually does

TLS termination

Reverse proxies typically handle HTTPS for backends. The proxy holds the certificate, decrypts inbound traffic, and forwards plain HTTP to backends on the internal network (or re-encrypts to backends that require TLS). This means:

• Backend applications don't need to handle TLS — simpler code, no certificate management per app.
• The proxy can inspect HTTP for routing, security, caching.
• Backend connections may use HTTP/2 multiplexing efficiently.
• Certificate rotation happens in one place.

Load balancing

Distribute requests across multiple backend instances. Common algorithms:

• Round-robin: Take turns sending to each backend.
• Least connections: Send to whichever backend has fewest active connections.
• IP hash / sticky sessions: Same client always lands on the same backend.
• Weighted: Send proportionally based on backend capacity.

Combined with health checks: proxy periodically verifies each backend; unhealthy backends are removed from rotation automatically.

Request routing

Different URLs go to different backends:

/api/* → backend-api-cluster
/static/* → static-file-server (or CDN)
/admin/* → backend-admin (with auth)
/ws/* → websocket-server
/* → main-app-server

A single domain can route many distinct services through one proxy. This is the foundation of micro-frontends and microservices architectures.

Caching

Cache backend responses based on Cache-Control headers (similar to CDN caching but at your edge rather than third-party). Reduces backend load for cacheable content.

Security and WAF

Apply firewall rules, WAF (Web Application Firewall), bot detection, rate limiting at the proxy. The backend never sees suspicious traffic. Many production deployments combine reverse proxy with WAF features (ModSecurity in NGINX, Cloudflare WAF, AWS WAF).

Compression

gzip or Brotli compression at the proxy. Backend doesn't need to handle compression; proxy does it consistently for all backends.

Connection management

Maintain keep-alive connections to backends; multiplex HTTP/2 or HTTP/3. Buffer slow clients so they don't tie up backend resources.

Common reverse proxy products

Reverse proxy in front of small services

Even for hobbyist or home-lab deployments, a reverse proxy is often the right pattern. Common setups:

• Home server with multiple services (Plex, NextCloud, Home Assistant). Single port forward to the reverse proxy; proxy routes to each service by hostname.
• Personal VPS hosting a static site, a small API, and a webhook handler. Reverse proxy lets all three coexist on port 443.
• Microservices development on localhost. Traefik or Caddy can spin up TLS-terminated routes to multiple local services as you develop.

Caddy: easy HTTPS

For solo developers and small deployments, Caddy is worth mentioning specifically because it handles HTTPS automatically. A 5-line Caddyfile:

example.com {
    reverse_proxy localhost:8080
}
api.example.com {
    reverse_proxy localhost:9090
}

Caddy obtains and renews Let's Encrypt certificates automatically, serves HTTPS, and proxies to the backends. No certificate management, no cron jobs for renewal. For SMB-style deployments where simplicity matters more than peak performance, this is the lowest-friction option.

Reverse proxy in cloud environments

• AWS Application Load Balancer (ALB) — managed L7 reverse proxy with path/host-based routing, AWS WAF integration, automatic certificate management via ACM.
• Azure Application Gateway — equivalent for Azure.
• GCP HTTP(S) Load Balancer — global L7 reverse proxy with anycast IP.
• Kubernetes Ingress controllers — NGINX, Traefik, Envoy run inside a cluster to provide reverse proxy services for cluster-internal apps.

Cloud-managed reverse proxies trade some flexibility for ease of operation. They handle SSL, scaling, and high availability without you managing the proxy infrastructure itself.

Frequently Asked Questions

What is the difference between a reverse proxy and a forward proxy?

A forward proxy sits between clients and the internet, forwarding outbound requests on behalf of clients — used for filtering, anonymization, or accessing restricted content. A reverse proxy sits in front of servers, forwarding inbound requests on behalf of those servers — clients don't know there are multiple backend servers; they only see the reverse proxy. Forward proxies face the client; reverse proxies face the server.

What are common reverse proxy products?

NGINX (the most widely deployed), Apache HTTP Server with mod_proxy, HAProxy (specialized for load balancing), Traefik (cloud-native, auto-discovery), Caddy (automatic HTTPS), Envoy (modern, used in service meshes), AWS ALB, Cloudflare (which is a reverse proxy + CDN + WAF combined). For SMB use, NGINX and Caddy are the most common open-source choices; managed services like Cloudflare and AWS ALB are the cloud equivalents.

Why use a reverse proxy?

Several reasons: (1) TLS termination — handle HTTPS at the proxy so backend apps don't need to; (2) load balancing across multiple backend instances; (3) caching of frequently-requested responses; (4) request routing — different URLs to different backend services; (5) security — hide backend implementation, add WAF, rate limiting; (6) protocol translation — HTTP/2 in, HTTP/1.1 to backend; (7) compression. Even single-backend deployments benefit from the consolidation of cross-cutting concerns at the proxy.

Does a CDN count as a reverse proxy?

Yes — a CDN is effectively a globally-distributed reverse proxy. Each edge POP is a reverse proxy in front of the origin server, with the additional capabilities of caching content close to users and absorbing traffic at the edge. The conceptual model is identical: clients connect to the proxy, the proxy fetches from backend, the proxy returns the response. CDNs add geographic distribution, dedicated security features (DDoS, WAF), and global anycast routing on top of the basic reverse-proxy model.