Proxy vs Reverse Proxy
Reverse proxies are used in virtually every production system. They handle TLS termination, load balancing, caching, rate limiting, and DDoS protection.
Quick answer: Proxy vs Reverse Proxy
Proxy vs Reverse Proxy is covered here as a practical system design concept. Reverse proxies are used in virtually every production system. They handle TLS termination, load balancing, caching, rate limiting, and DDoS protection. Use it to understand the Networking idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
A forward proxy hides clients from servers (VPN, corporate proxy). A reverse proxy hides servers from clients (Nginx, Cloudflare). In production, reverse proxies handle TLS termination, load balancing, caching, and DDoS protection — they sit in front of virtually every web application.
| Aspect | Details |
|---|---|
| What it is | A server that intercepts all client requests before they reach backend servers |
| When to use | TLS termination, caching static assets, load distribution, hiding internal topology |
| When NOT to use | Simple single-server apps with no security requirements |
| Real-world example | Cloudflare proxies ~20% of all web traffic; Netflix uses Zuul as their edge proxy |
| Interview tip | Clarify forward vs reverse — interviewers test whether you know the difference |
| Common mistake | Saying 'proxy' without specifying direction; forgetting it becomes a single point of failure |
| Key tradeoff | Extra network hop (~1ms latency) vs. caching, security, and operational flexibility |
Why This Matters
Reverse proxies are used in virtually every production system. They handle TLS termination, load balancing, caching, rate limiting, and DDoS protection. Understanding the difference is a common interview question.
The Building Blocks
- Forward proxy: Client → Proxy → Internet. Used for: anonymous browsing, content filtering, caching. The server does not know the client's real IP.
- Reverse proxy: Internet → Reverse Proxy → Backend servers. Used for: load balancing, SSL termination, caching, security. The client does not know the backend server's IP.
- Common reverse proxies: Nginx, HAProxy, Cloudflare, AWS ALB, Envoy.
- SSL/TLS termination: The reverse proxy handles encryption/decryption, so backend servers only deal with plain HTTP.
- API Gateway as reverse proxy: API gateways like Kong or AWS API Gateway are specialized reverse proxies that add authentication, rate limiting, and request transformation.
Under the Hood
In a typical setup, Nginx acts as a reverse proxy: it listens on port 443 (HTTPS), terminates SSL, and forwards requests to backend application servers on port 8080 (HTTP). It can also cache static assets, compress responses (gzip), and load balance across multiple backend instances.
How Companies Actually Do This
Cloudflare acts as a reverse proxy for millions of websites, providing DDoS protection, CDN caching, and SSL termination.
Netflix uses Zuul as their API gateway/reverse proxy, handling request routing, load balancing, and resilience for their microservices.
Corporate networks use forward proxies to filter employee internet access and log browsing activity.
Common Pitfalls
- Confusing forward and reverse proxies
- Not making the reverse proxy itself highly available
- Passing sensitive headers through the proxy without sanitization
Interview Questions Worth Practicing
- What is the difference between a forward proxy and a reverse proxy?
- Why would you use a reverse proxy?
- How does a reverse proxy enable SSL termination?
The Tradeoffs
- Reverse proxy overhead: Adds a network hop and potential latency (usually <1ms).
- Single point of failure: The reverse proxy itself must be highly available.
- Complexity: Adding a proxy layer means another component to configure, monitor, and maintain.
How to Explain This in an Interview
Here is how I would explain Proxy vs Reverse Proxy in a system design interview:
A reverse proxy sits between clients and your servers. Every request hits the proxy first. The proxy can terminate TLS so your backend doesn't deal with certificates, cache responses so repeated requests never hit your servers, and load balance across multiple backend instances. Think of Nginx in front of your app servers. The key thing interviewers want to hear: it decouples clients from your infrastructure. You can swap, scale, or restart backend servers without clients noticing. If asked about forward proxies, mention VPNs and corporate proxies — they hide the client's identity from the server, which is the opposite direction.
Related Topics
Original DosiBridge notes for Proxy vs Reverse Proxy
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Proxy vs Reverse Proxy is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Packet Path: For Proxy vs Reverse Proxy, decide the packet path before choosing tools; otherwise the design looks clean but fails when proxy changes.
- Timeout Budget: For Proxy vs Reverse Proxy, decide the timeout budget before choosing tools; otherwise the design looks clean but fails when vs changes.
- TLS Boundary: For Proxy vs Reverse Proxy, decide the TLS boundary before choosing tools; otherwise the design looks clean but fails when reverse changes.
- Proxy Behavior: For Proxy vs Reverse Proxy, decide the proxy behavior before choosing tools; otherwise the design looks clean but fails when proxy changes.
- Backpressure: For Proxy vs Reverse Proxy, decide the backpressure before choosing tools; otherwise the design looks clean but fails when proxy changes.
Production review question
If a team adopts Proxy vs Reverse Proxy, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track proxy-proxy health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Proxy vs Reverse Proxy, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.