system-design

Proxies: Forward and Reverse

A middleman for network traffic. Which direction it faces determines whether it’s protecting your users or your servers.

Prerequisites: Networking 101, Load Balancers Time to read: ~12 minutes

The problem

Client talks to server. Simple. But sometimes you want something in the middle — to cache, to filter, to hide who’s talking, to add security, to route.

A proxy is that middle thing. The only question is which side it works for, and that single distinction is what interviewers are checking when they ask.

Forward proxy: works for the client

Sits in front of clients. The server has no idea who the real client is.

[Client] → [Forward Proxy] → Internet → [Server]
                ↑
        acts on behalf of the client;
        the server sees the proxy's IP

What it’s for:

Corporate egress control. All employee traffic goes through it; it blocks categories, logs access, and enforces policy.
Anonymity. The destination sees the proxy’s IP, not yours. (VPNs are a related idea at a lower layer.)
Bypassing geo-restrictions. Appear to be somewhere else.
Caching for many clients. A university proxy caches a popular download once for 10,000 students. (Less relevant now that everything is HTTPS and CDN-cached.)
Egress security. Inspect and control what leaves your network — a real requirement in regulated environments, and how data-exfiltration controls work.

In system design terms: you’ll mostly meet forward proxies as a constraint rather than a component you design. “Our enterprise customers are behind a corporate proxy” affects TLS, IP allowlists, and whether WebSockets work at all.

Examples: Squid, corporate web gateways, Zscaler, and a NAT gateway (which is the same idea at the network layer — your VPC’s private instances reach the internet through it).

Reverse proxy: works for the server

Sits in front of servers. The client has no idea which backend served it.

[Client] → Internet → [Reverse Proxy] → [Server 1]
                            │          → [Server 2]
                            ↓          → [Server 3]
                  acts on behalf of the servers;
                  the client sees only the proxy

This is the one you’ll actually design with. Nearly every production system has one, and it’s doing more than you think:

Function	Detail
Load balancing	→ Load Balancers — an L7 load balancer is a reverse proxy
TLS termination	Handle HTTPS once, centrally; backends speak plain HTTP inside the VPC
Caching	Serve repeat requests without touching the app at all
Compression	gzip/brotli once at the edge instead of in every service
Security	Hide backend topology; block bad requests before they reach your code; WAF rules
Rate limiting	Cheap rejection before you spend application CPU
Static file serving	Nginx serves files far faster than your app framework
Request routing	`/api/` → API servers, `/static/` → the CDN, `/ws` → the WebSocket tier
Header manipulation	Add `X-Forwarded-For`, `X-Request-ID`, security headers
Canary routing	Send 5% of traffic to the new version

🚨 The distinction in one line: a forward proxy hides the client from the server; a reverse proxy hides the server from the client. If you can say that sentence, you’ve answered the question.

Examples: Nginx, HAProxy, Envoy, Traefik, Caddy, AWS ALB, Cloudflare.

The relationship to load balancers, CDNs, and gateways

These terms overlap heavily and beginners find it confusing. The honest answer:

Component	It is…	What distinguishes it
Reverse proxy	The general category	Anything sitting in front of servers
Load balancer	A reverse proxy	Emphasis on distribution + health checking
API gateway	A reverse proxy	Emphasis on auth, rate limiting, aggregation, per-API policy → API Gateway
CDN	A globally distributed reverse proxy	Emphasis on geographic caching → CDN
Service mesh sidecar	A reverse and forward proxy per service	Emphasis on service-to-service mTLS, retries, telemetry → Service Mesh

They’re the same underlying software category (Nginx and Envoy can play every one of these roles), differentiated by where you put it and what you configure it to emphasize. Saying that in an interview is better than pretending they’re fundamentally different things.

Practical concerns that show up in production

Losing the client’s IP

Once traffic goes through a proxy, your application sees the proxy’s IP on every request. That breaks rate limiting, geo-logic, fraud detection, and audit logs.

The fix is the X-Forwarded-For header (or the standardized Forwarded header):

X-Forwarded-For: 203.0.113.5, 198.51.100.17
                 ↑ original client   ↑ first proxy

🚨 Security trap: X-Forwarded-For is client-supplied and trivially spoofable. If you rate limit by the leftmost value, an attacker sends a fake one and bypasses your limits entirely. The correct approach is to configure how many trusted proxies sit in front of you, and only trust that many entries from the right. Every serious framework has a trusted_proxies setting; use it.

Buffering and timeouts

Reverse proxies buffer by default. That’s usually good (a slow client can’t tie up a backend worker — this is the defence against slowloris attacks), but it breaks streaming responses and server-sent events unless you disable it for those routes.

And every proxy has its own timeouts, which must be longer than your application’s. A classic confusing bug: Nginx’s default 60-second proxy_read_timeout returning a 504 while your application happily completes the work at 70 seconds. The user sees an error; your logs show success.

Rule: timeouts should decrease as you move inward. Client 30s → proxy 25s → service 20s → database 15s. Anything else produces work that nobody is waiting for. → Retries & Timeouts

WebSockets need explicit configuration

WebSockets start as an HTTP request with an Upgrade header. Proxies that don’t forward that header (and don’t hold the connection open) silently break real-time features. If a design involves WebSockets, the proxy layer needs proxy_http_version 1.1 plus Upgrade/Connection headers, and long idle timeouts.

⚖️ Trade-offs

Adding a reverse proxy	Gain	Cost
Any proxy hop	Centralized TLS, caching, routing, security	+0.1–1 ms latency; another component to run and monitor
TLS termination at the proxy	Backends don’t handle certs or crypto	Internal traffic is plaintext unless re-encrypted
Caching at the proxy	Big origin load reduction	Invalidation complexity; risk of serving private data if `Vary` is wrong
Buffering	Slow clients can’t tie up backends	Breaks streaming/SSE unless disabled per route

In the real world

Nginx was created specifically to solve C10K as a reverse proxy in front of Apache, which couldn’t handle many concurrent connections. That’s still the dominant deployment pattern: a fast event-driven proxy fronting slower application processes.
Cloudflare is a reverse proxy for millions of sites. Because all traffic flows through it, it can absorb DDoS, cache globally, and apply WAF rules — the “just put a proxy in front” idea taken to planetary scale.
Envoy sidecars in a service mesh are both: a reverse proxy for inbound traffic to their service and a forward proxy for that service’s outbound calls. That symmetry is what lets a mesh implement mTLS, retries, and tracing without touching application code.

🚨 Interview traps

Mixing up forward and reverse. Know the one-line distinction.
Trusting X-Forwarded-For blindly when rate limiting or geo-blocking.
Not accounting for the proxy’s timeouts in a latency budget.
Forgetting the proxy is a hop that can fail. It needs redundancy like anything else.
Treating “reverse proxy,” “load balancer,” and “API gateway” as three unrelated things. They’re the same category with different emphases; say so.

🎙️ Soundbites

“A forward proxy hides the client from the server; a reverse proxy hides the servers from the client. What we want here is the reverse kind.”
“I’d terminate TLS at the reverse proxy and pass plain HTTP inside the VPC, unless compliance requires end-to-end encryption — in which case we re-encrypt to origin.”
“We’d need to trust X-Forwarded-For carefully — configure the number of proxies in front and only read that far in, otherwise clients can spoof their IP and bypass rate limits.”
“Timeouts need to shorten as we go inward, or the proxy gives up on work the backend is still doing.”

🛠️ Try it

Configure Nginx as a reverse proxy with caching, and watch the origin go quiet:

proxy_cache_path /tmp/cache levels=1:2 keys_zone=my_cache:10m max_size=1g;

server {
    listen 8080;
    location / {
        proxy_pass http://localhost:3000;
        proxy_cache my_cache;
        proxy_cache_valid 200 60s;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        add_header X-Cache-Status $upstream_cache_status;   # HIT / MISS
    }
}

Hit it repeatedly and watch X-Cache-Status flip from MISS to HIT. Then check your application logs — the requests simply stop arriving. That’s the origin-load reduction a proxy buys you, and it’s larger than most people expect.

Then try spoofing: curl -H "X-Forwarded-For: 1.2.3.4" localhost:8080 and see what your app logs. That’s the security trap, demonstrated in one command.

Check yourself

1. Your app logs show every request coming from 10.0.1.5. What's happening and how do you fix it?

That's your reverse proxy's IP — the app sees the proxy as the client, because the proxy terminated the original connection and opened a new one. Fix: have the proxy set `X-Forwarded-For` (or `Forwarded`) with the real client IP, and configure your framework's trusted-proxy setting so it reads the correct entry. Don't just take the leftmost value — that's client-controlled and spoofable.

2. Why must proxy timeouts be longer than application timeouts?

Because whoever times out first determines what the user sees. If the proxy gives up at 60 s while the app finishes at 70 s, the user gets a 504 even though the work succeeded — and if that request had side effects (a payment, an order), you now have a client that thinks it failed and a backend that thinks it succeeded. Timeouts should decrease inward (client > proxy > service > database) so that the innermost component gives up first and the outer layers can report a coherent error.

3. How is an API gateway different from a plain reverse proxy?

It isn't, structurally — an API gateway *is* a reverse proxy, usually built on the same software. The difference is emphasis and feature set: gateways focus on API-specific concerns (authentication and token validation, per-consumer rate limiting and quotas, request/response transformation, aggregating several backend calls into one response, developer portals, per-route policy). A plain reverse proxy focuses on routing, TLS, and caching. Use the term that matches what you're emphasizing.

4. Your streaming endpoint works locally but sends nothing until it finishes when deployed. Why?

The reverse proxy is buffering the response — it collects the full body before forwarding, which is the default and is good for normal responses (it protects backends from slow clients). For streaming, SSE, or chunked responses you must disable it for that route (`proxy_buffering off` in Nginx, plus `X-Accel-Buffering: no` as a per-response override). Also check that the proxy's read timeout is long enough for a long-lived stream.

5. What does a service mesh sidecar have to do with proxies?

It's both kinds at once: a reverse proxy for traffic coming *into* its service, and a forward proxy for traffic that service sends *out*. Because every call in and out passes through it, the mesh can enforce mTLS, retries, timeouts, circuit breaking, traffic splitting, and distributed tracing without any application code changing. It's the proxy pattern applied per-instance instead of centrally.