Reverse proxy

Overview

A reverse proxy receives client requests on behalf of one or more backend servers. Clients only ever see the proxy's address; the proxy decides which backend handles each request, forwards it, and returns the response. It is the standard front door of almost every production web system.

Because every request passes through it, the reverse proxy is the natural place for shared concerns: TLS termination, load balancing, caching, compression, request buffering, security headers, rate limiting, and routing by host or path. Offloading these keeps application servers simple and focused on business logic.

When to use it

• Exposing multiple backend instances behind one address.
• Terminating TLS in one place.
• Serving static files and caching responses.
• Routing /api to one service and /app to another.
• Protecting slow app servers from slow clients (buffering).

Where it shows up in interviews

Where it is used in real software

Key terms

Upstream / origin

The backend servers the proxy forwards to.

TLS termination

Decrypting HTTPS at the proxy.

Request buffering

The proxy receives the full request before sending it upstream, protecting backends from slow clients.

Path / host routing

Choosing an upstream based on the URL path or Host header.

How it works, step by step

1. 1
   Accept and decrypt

   The proxy terminates TLS and parses the HTTP request.

2. 2
   Check cache

   Serve cached responses immediately when valid.

3. 3
   Route

   Match host and path rules to pick an upstream group.

4. 4
   Balance and forward

   Pick a healthy instance and forward over a pooled connection.

5. 5
   Transform the response

   Compress, add security headers, cache, and log.

What moves from the app into the reverse proxy

Responsibilities before and after adding a proxy

The app becomes simpler and scales by adding instances behind the proxy, while cross-cutting policies live in one configuration.

Implementation

1upstream api  { server 10.0.1.10:8080; server 10.0.1.11:8080; keepalive 32; }2upstream web  { server 10.0.2.10:3000; }3 4proxy_cache_path /var/cache/nginx keys_zone=pages:50m max_size=1g inactive=10m;5 6server {7    listen 443 ssl http2;8    server_name app.example.com;9    gzip on;10 11    location /api/ {12        proxy_pass http://api;13        proxy_http_version 1.1;14        proxy_set_header Connection "";15        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;16        proxy_set_header X-Forwarded-Proto $scheme;17    }18 19    location /static/ {20        root /var/www;              # served without touching the app21        expires 1y;22    }23 24    location / {25        proxy_cache pages;26        proxy_cache_valid 200 60s;27        proxy_pass http://web;28    }29}

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• Caching personalized pages.

  Fix: Vary cache keys on user identity or bypass the cache for authenticated requests.

• Not forwarding the original scheme and IP.

  Fix: Set X-Forwarded-Proto and X-Forwarded-For so the app generates correct URLs and logs.

Interview questions

Practice problems