Skip to main content

Proxy vs Reverse Proxy

A proxy is any server that sits between a client and a destination server, forwarding requests on one side's behalf. "Forward proxy" and "reverse proxy" describe the exact same mechanism — an intermediary relaying traffic — but they sit on opposite sides of the relationship, and mixing them up in an interview is a fast way to signal you haven't fully internalized either one. The question that disambiguates them instantly is: whose identity is being hidden from whom?

Forward proxy: hides the client from the server​

A forward proxy sits in front of one or more clients. The client is configured to send its requests to the proxy, which forwards them on to whatever destination the client asked for. From the destination server's point of view, the request appears to come from the proxy, not from the original client.

Typical uses: corporate networks routing all employee traffic through a proxy for content filtering and logging, VPN-like services that anonymize a client's origin, and caching proxies that save bandwidth by serving repeated requests from a shared cache instead of re-fetching them.

Reverse proxy: hides the server(s) from the client​

A reverse proxy sits in front of one or more servers. The client thinks it's talking directly to the destination, but it's actually talking to the reverse proxy, which forwards the request to one of potentially many backend servers and returns the response. From the client's point of view, there's a single, stable-looking endpoint — the actual number, identity, and health of the backend servers behind it are invisible.

System Design Lab

This is why reverse proxies show up everywhere in system design: they're the natural place to put anything that should apply uniformly in front of a whole fleet of servers, without every backend having to implement it itself.

What a reverse proxy is used for​

  • Load balancing — distributing requests across the backend pool (in practice, most reverse proxy software — NGINX, HAProxy, Envoy — is a load balancer; see Load Balancing).
  • TLS termination — decrypting HTTPS at the proxy so backend servers only have to speak plain HTTP internally, centralizing certificate management in one place.
  • Caching — serving frequently requested, cacheable responses directly from the proxy without hitting a backend server at all.
  • Security and rate limiting — a reverse proxy is a natural chokepoint for a web application firewall, IP allowlisting, or rate limiting, since every request already has to pass through it.
  • Hiding topology — the client never learns how many backend servers exist, what their internal IPs are, or which one served a given request, which is both an operational convenience (you can add, remove, or replace backends freely) and a security boundary.

This overlaps heavily with an API Gateway, which is really a reverse proxy with extra application-aware responsibilities layered on (authentication, request transformation, routing by API version). If you're asked to distinguish them, the honest answer is that an API gateway is a specialized reverse proxy, not a fundamentally different mechanism.

Why this matters in an interview​

Saying "we'll put a reverse proxy in front of the fleet" is a stronger, more specific answer than "we'll add a load balancer," because it signals you know the proxy is also your natural place for TLS termination, caching, and security policy — not just traffic splitting. It's also worth being precise about direction: if an interviewer asks "what does a forward proxy protect," the answer is the client's identity and browsing behavior; a reverse proxy protects and manages the servers.

Adding a reverse proxy: pros and cons​

Pros

  • Centralizes TLS termination, caching, and security policy in one place instead of every backend
  • Hides backend topology — servers can be added, removed, or replaced transparently
  • Natural integration point for load balancing and health-check-based failover

Cons

  • Adds a network hop and a new potential single point of failure if not itself made redundant
  • Centralizes risk — a misconfiguration or outage at the proxy affects every backend behind it
  • Extra component to operate, monitor, and scale independently of the application servers

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.