Chapter 8 — Proxies: The Middlemen

A proxy is any system that sits between a client and a server, forwarding requests on behalf of one to the other. The key question is: who does the proxy work for?

Forward Proxy

A forward proxy sits in front of clients. It makes requests to the internet on the client's behalf.

[Your Browser]
      │
      │  Configured to use proxy: proxy.company.com:3128
      ▼
[Forward Proxy Server]  ← client knows about this and uses it intentionally
      │
      │  Makes request as if it is the client
      ▼
[Internet] → [Netflix]

Netflix sees the request coming FROM the proxy's IP — not your IP.

Who Uses Forward Proxies

Corporate networks:

All employees → Corporate forward proxy → Internet
Proxy enforces:
  • Block social media (facebook.com → 403)
  • Log all URLs visited
  • Cache popular websites (save bandwidth)
  • Decrypt HTTPS (SSL inspection — controversial)
  • Enforce content policies

Privacy / VPN:

You → VPN server (acts as forward proxy) → Netflix
Netflix sees VPN server's IP, not your real IP.
Your ISP sees encrypted traffic to VPN, not which sites you visit.

Scraping / Automation:

Scraper → Pool of forward proxies → Target website
Rotates IPs so the target doesn't rate-limit one source.

How the Browser Uses a Forward Proxy

There are two ways:

1. HTTP CONNECT method (tunneling — for HTTPS):

Browser → Proxy: CONNECT www.netflix.com:443 HTTP/1.1
Proxy → Netflix: Opens TCP connection to netflix.com:443
Proxy → Browser: 200 Connection Established

Now the proxy passes bytes blindly in both directions.
The proxy cannot see inside the encrypted TLS tunnel.
Browser and Netflix speak TLS directly through the tunnel.

2. HTTP proxy (for plain HTTP only — legacy):

Browser → Proxy: GET http://example.com/ HTTP/1.1
                 Host: example.com
                 Proxy-Authorization: Basic ...
Proxy → example.com: GET / HTTP/1.1 (forwards the request)
example.com → Proxy: 200 OK [content]
Proxy → Browser: 200 OK [content]

SSL Inspection (HTTPS Interception)

Some corporate proxies perform a "man-in-the-middle" on HTTPS:

Browser → Proxy: CONNECT netflix.com:443
Proxy → Browser: 200 Established (but proxy doesn't connect to Netflix yet)
Browser → Proxy: TLS ClientHello
Proxy → Browser: TLS ServerHello + [fake netflix.com cert signed by corp CA]
                 (The corp CA cert is pre-installed in all company browsers)
Browser → Proxy: TLS established (trusted, because corp CA is trusted)

Proxy → Netflix: Opens real TLS connection to netflix.com
Netflix → Proxy: Real TLS session

Proxy sees decrypted content, can log/filter, then re-encrypts to Netflix.

This is legitimate inside corporations where employees consent, but it is a MITM attack when done without consent.

Reverse Proxy

A reverse proxy sits in front of servers. Clients talk to the reverse proxy thinking it is the server.

[Your Browser]
      │
      │  Requests netflix.com (has no idea a proxy is involved)
      ▼
[Reverse Proxy — Nginx / Envoy / Cloudflare]
      │
      │  Forwards to appropriate backend (client never knows)
      ▼
[Backend Server 1]  or  [Backend Server 2]  or  [Backend Server 3]

You see responses from "nginx" — you never know 10.0.4.55 exists.

What Reverse Proxies Do

TLS Termination:

Client ──[HTTPS]──► Reverse Proxy ──[HTTP]──► Backend
The reverse proxy holds the TLS certificate and private key.
Backend servers don't need to handle TLS — simpler, lighter.

Caching:

First request for /static/logo.png:
  Proxy → Backend → gets logo → caches it → returns to client

Second request for /static/logo.png:
  Proxy → cache HIT → returns directly → backend not involved
  Latency: 1ms (from cache) instead of 20ms (from backend)

Load Balancing:

Round-robin distribution:
  Request 1 → Backend A
  Request 2 → Backend B
  Request 3 → Backend C
  Request 4 → Backend A
  ...

Reverse proxy health-checks backends.
Removes unhealthy backends from rotation automatically.

Rate Limiting:

limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    proxy_pass http://backend;
}

→ Max 100 requests/second per IP.
  First 20 over that limit: allowed (burst).
  After burst: 429 Too Many Requests.

Request/Response Modification:

Add headers before forwarding to backend:
  X-Real-IP: 203.0.113.45        (client's real IP — otherwise backend sees proxy IP)
  X-Forwarded-For: 203.0.113.45  (standard header for proxied IPs)
  X-Forwarded-Proto: https       (original protocol — backend receives HTTP from proxy)

Remove sensitive headers from response:
  Server: nginx                   (don't expose Apache/version info)
  X-Powered-By: [removed]        (don't expose PHP/Express/etc)

Compression:

Backend returns uncompressed HTML (100KB).
Reverse proxy compresses to Brotli (30KB).
Client receives 70% smaller response.
Backend doesn't need to implement compression.

A/B Testing / Canary Deployments:

10% of requests → Backend v2 (new version — canary)
90% of requests → Backend v1 (stable)
Reverse proxy decides based on cookie, IP hash, or random.

Nginx as a Reverse Proxy — Config Example

upstream netflix_backends {
    least_conn;                         # Load balancing algorithm
    server 10.0.4.51:8080 weight=5;    # Backend 1 (5x weight)
    server 10.0.4.52:8080 weight=5;    # Backend 2 (5x weight)
    server 10.0.4.53:8080 weight=1;    # Backend 3 (canary, 1x weight)
    keepalive 32;                       # Keep 32 connections warm
}

server {
    listen 443 ssl http2;
    server_name www.netflix.com;

    # TLS termination
    ssl_certificate     /etc/ssl/netflix.crt;
    ssl_certificate_key /etc/ssl/netflix.key;
    ssl_protocols       TLSv1.3;
    ssl_ciphers         TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Security headers
    add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Frame-Options "DENY" always;

    # Rate limiting
    limit_req zone=per_ip burst=50 nodelay;

    location / {
        proxy_pass http://netflix_backends;
        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;

        # Timeouts
        proxy_connect_timeout 5s;
        proxy_read_timeout    30s;

        # Caching for static assets
        location ~* \.(js|css|png|jpg|woff2)$ {
            proxy_cache static_cache;
            proxy_cache_valid 200 1d;
            add_header X-Cache-Status $upstream_cache_status;
        }
    }
}

Transparent Proxy

A transparent proxy intercepts traffic without the client knowing or being configured to use it. The client's browser is not configured with any proxy settings — yet all traffic goes through the proxy.

[Your Browser] → [Your Router] → [Transparent Proxy] → [Internet]
                       ↑
              Network-level interception
              All TCP port 80/443 traffic redirected to proxy
              Browser is unaware

Used by:
  • ISPs (caching, content filtering)
  • Coffee shop Wi-Fi (inject ads)
  • Government censorship firewalls
  • Corporate networks (no browser config required)

For HTTP: transparent proxy can read and modify traffic. For HTTPS: transparent proxy can only see IP + SNI (hostname). Cannot decrypt without SSL interception.

Service Mesh — Proxies Inside the Datacenter

In a microservices architecture, every service calls many other services. How do you handle:

• mTLS between services?
• Retries, timeouts, circuit breaking?
• Traffic routing for canary deployments?
• Distributed tracing?

A service mesh uses a sidecar proxy — a proxy deployed alongside every service instance.

Service A                Service B
┌────────────────┐      ┌────────────────┐
│ App (Port 8080)│      │ App (Port 8080)│
│                │      │                │
│ Envoy Proxy    │      │ Envoy Proxy    │
│ (sidecar)      │      │ (sidecar)      │
└───────┬────────┘      └────────┬───────┘
        │                        │
        └──── mTLS ─────────────►│
        All traffic between services goes through sidecars.
        The app doesn't know about mTLS, retries, or tracing — Envoy handles it.

Envoy is a common sidecar/data-plane proxy in service-mesh architectures. Istio and Linkerd are popular service mesh frameworks.

Proxy Headers — Knowing the Real Client IP

When a reverse proxy forwards your request to the backend, the backend sees the proxy's IP as the source, not your real IP. These headers convey the original client's IP:

X-Forwarded-For: 203.0.113.45, 10.0.0.1
                 ↑              ↑
          original client   intermediate proxy

X-Real-IP: 203.0.113.45
           ↑ The first (original) client IP

Forwarded: for=203.0.113.45;proto=https;by=10.0.0.1
           ↑ RFC 7239 standard (newer, single header)

Security caveat: X-Forwarded-For can be spoofed by clients. If a client sends X-Forwarded-For: 1.2.3.4, the backend sees 1.2.3.4, [proxy IP]. For rate limiting and security decisions, only trust the rightmost IP (added by your own proxy) — not client-supplied values.

Forward vs Reverse Proxy — Quick Comparison