Proxy vs Reverse Proxy vs LB — Traced With a Real Request
The difference, traced
All three sit in the middle; the trick is whom they stand in front of.
Forward proxy — acts for the CLIENT
Your laptop (10.0.0.9) is set to use proxy 10.0.0.1. You request example.com; the proxy opens its own connection and forwards it, so example.com sees the proxy's IP, not yours. Used for egress control, filtering, caching.
Reverse proxy — acts for the SERVER
DNS for shop.com points at Nginx. The browser only ever talks to Nginx, which terminates TLS, routes by path to a backend on the private network, and carries the real client IP in X-Forwarded-For. The client never learns the backend IPs.
The same trace, step by step in text
| Step | Hop | What actually crosses the wire |
|---|---|---|
| 1 | browser → Nginx 203.0.113.5:443 | TLS handshake terminates HERE — SNI shop.com; then GET /api/orders, Host: shop.com. |
| 2 | inside Nginx | Routes /api/orders by path to the orders backend pool. |
| 3 | Nginx → backend 10.0.1.20:8080 | A NEW connection from the keep-alive pool; Nginx adds X-Forwarded-For: 198.51.100.7 and X-Request-ID. |
| 4 | backend → Nginx | The backend replies to Nginx — it has never seen the client's TCP connection. |
| 5 | Nginx → browser | Nginx streams the response back over the original TLS session; the client never learns 10.0.1.20. |
| 6 | forward-proxy contrast: laptop 10.0.0.9 → proxy 10.0.0.1 | The request line names the destination INSIDE the payload — CONNECT example.com:443 for HTTPS, or an absolute-URI GET http://example.com/ HTTP/1.1 for plain HTTP — the giveaway that the client, not the server, opted into this proxy. |
Load balancer
A reverse proxy specialised to spread requests across N identical backends (round-robin/least-conn) with health checks. Most LBs in system-design interviews are reverse proxies, because they terminate the client connection and open a new one to a backend. Packet-forwarding L4 balancers such as LVS/IPVS in DSR mode or plain destination-NAT forwarding are an exception: they rewrite addresses and forward the same packets without terminating, so by the strict definition they are load balancers but not reverse proxies. See What is a Proxy Server for the distinction.
Takeaways
- Forward proxy: server sees the proxy's IP — hides clients.
- Reverse proxy: client sees only the proxy — TLS, routing, hides backends.
- LB: reverse proxy picking one of N identical backends. An API gateway is an L7 reverse proxy with auth/rate-limiting.
L0 · a forward proxy hides the client from the destination; a reverse proxy/LB hides the destination from the client — same shape, opposite loyalty.
L1 · ⑤ Adversary/Edge — "how do you trust the client IP behind a proxy chain?"
Trap: "Just read X-Forwarded-For — it's the real client IP."
Bar: X-Forwarded-For is only a header, forgeable by any client; the origin must trust it only when the TCP peer itself is a known proxy IP, and each hop must strip any inbound client-supplied value before appending its own observed address. Trust follows the TCP peer chain, not header content — that's what Nginx's real_ip/set_real_ip_from and cloud LB "trusted proxy" ranges enforce. reverse-proxy-in-practice: zero-trust
L2 · ② Failure — "does adding a reverse proxy make the system more or less reliable?"
Trap: "It's just a pass-through, it can't be a point of failure."
Bar: The proxy is a stateful process holding open sockets, health-check state, and routing tables; if it crashes or a bad config reload drops connections, every healthy backend behind it goes unreachable. Production runs it as an HA pair (VRRP/keepalived floating IP, or anycast) with its own health checks — the fix for "the load balancer is a SPOF" is to load-balance the load balancer. HA & fault tolerance
L3 · ① Concurrency — "does one client connection map to one backend connection?"
Trap: "It's a 1:1 relay, so client and backend connections are the same thing."
Bar: The proxy decouples them: thousands of short-lived, TLS-heavy client connections multiplex onto a small pool of persistent, keep-alive backend connections, amortizing handshake cost. That pool has a fixed size — once every pooled connection is busy, requests queue at the proxy even though backends still have spare CPU. LB algorithms traced
L4 · ③ Scale — "one reverse proxy is maxed at 200k req/s, now what?"
Trap: "Just put it on a bigger box."
Bar: A single proxy hits file-descriptor, packet-rate, and TLS-CPU ceilings well before backends do, so hyperscale designs layer it — GSLB/DNS spreads across regions, an L4 LB spreads connections across a fleet of L7 reverse proxies, which then route and terminate TLS. Each tier scales independently because each saturates on a different resource. tier sizing & GSLB
L5 · ⑤ Adversary/Edge — "the LB terminates TLS, so traffic behind it in our VPC is safe?"
Trap: "TLS terminated once at the edge means everything downstream is already secure."
Bar: Termination decrypts to plaintext at the proxy; if an attacker footholds inside the VPC (compromised container, misrouted peering), that plaintext is fully readable, so zero-trust designs re-encrypt proxy-to-backend with a second, short-lived TLS/mTLS session rather than trusting the internal network. "TLS terminated" and "encrypted end-to-end" are different guarantees — only re-encryption closes that gap. TLS/mTLS handshake
The floor keeps dropping: now the two proxies in your HA pair have drifted — one still trusts an X-Forwarded-For range from a decommissioned edge network, the other doesn't. Which one authenticated the request that just got through, and how would you even tell from the logs?
Self-locate: died at L1 → mid-level; L4+ → staff signal.
Facing any new concept? Hit it with the six: concurrent? failing? at 100×? over time? adversarial? worth the cost? — that's the interviewer's whole playbook.
Re-authored from-scratch; diagram hand-authored (SVG) for this guide.
🤖 Don't fully get this? Learn it with Claude
Stuck on Proxy vs Reverse Proxy vs LB — Traced With a Real Request? Open Claude, copy a block below, and it'll teach you this exact concept — visually and interactively.
Build the mental picture, not memorization.
I just read a lesson on **Proxy vs Reverse Proxy vs LB — Traced With a Real Request** (System Design) and want to truly understand it. Explain Proxy vs Reverse Proxy vs LB — Traced With a Real Request from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Socratic — adapts to where you're stuck.
Teach me **Proxy vs Reverse Proxy vs LB — Traced With a Real Request** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Active recall exposes what you missed.
Quiz me on **Proxy vs Reverse Proxy vs LB — Traced With a Real Request** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.
Intuition + hook + flashcards for long-term memory.
Help me remember **Proxy vs Reverse Proxy vs LB — Traced With a Real Request** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.