Proxy & Reverse Proxy

A middle server that sits between a client and the real destination, on behalf of one side or the other.

What is it?

Sometimes a request doesn't go directly from a client to the server that will actually handle it — instead, it passes through a middle server first. A forward proxy sits in front of clients, forwarding their requests out on their behalf (often hiding who the client is, or filtering what they can reach). A reverse proxy sits in front of servers, forwarding incoming requests to whichever backend server should actually handle them (often hiding how many servers there are, or what they look like).

The two solve opposite problems, even though the underlying idea — a middle server relaying requests — is the same.

Explain like I'm 10

A forward proxy is like an assistant who makes calls on your behalf so the person on the other end never sees your number. A reverse proxy is like a company's reception desk — every visitor talks to the same receptionist, who then directs them to whichever employee should actually help, without the visitor ever needing to know who works where.

Examples

A reverse proxy routing to different backends

// Simplified reverse proxy config
routes: {
  "/api/*": "backend-server:4000",
  "/images/*": "image-server:5000",
  "/*": "web-server:3000",
}
// A request to /api/users is forwarded to backend-server,
// while a request to /home.html goes to web-server —
// the client only ever talks to one address.

How it works

A reverse proxy receives every incoming request first, inspects it (usually just the path or domain), and forwards it to whichever backend server is responsible for handling that kind of request — then relays the response back to the client as if it had come from the proxy itself. A forward proxy does the mirror image: it sits in front of clients, receiving their outgoing requests and forwarding them onward, often changing or hiding details about the original request.

Why does it exist?

Without a reverse proxy, clients would need to know the exact address of every individual backend service, and every one of those services would need to be directly exposed to the internet. A reverse proxy gives clients one single, stable address to talk to, while everything about how many servers exist and what they do stays hidden and free to change.

When to use it

Reach for a reverse proxy anytime you have more than one backend service (or more than one instance of the same service) and want clients to interact with a single, stable entry point — this is also exactly what a load balancer is, under the hood: a reverse proxy that distributes traffic across many identical servers. Reach for a forward proxy when clients need their outgoing requests filtered, cached, or have their identity hidden.

When not to use it

For a single, simple server with no need to route between multiple backends, a reverse proxy adds an extra network hop with no real benefit yet — you can always add one later as the system grows.

Common mistakes

  • Confusing a forward proxy (works on behalf of clients) with a reverse proxy (works on behalf of servers) — they solve different problems.

  • Forgetting that a reverse proxy is itself a piece of infrastructure that needs to stay up — if it goes down, so does access to everything behind it.

  • Exposing internal backend addresses directly instead of routing everything through the proxy, defeating the purpose of hiding the internal architecture.

Practice exercises

  1. Easy:

    Explain, in your own words, the difference between a forward proxy and a reverse proxy.

  2. Medium:

    Sketch (in words) a reverse proxy config that routes /api requests to one server and everything else to another.

  3. Hard:

    Explain how a load balancer and a reverse proxy relate to each other — is a load balancer a kind of reverse proxy, or something separate?

Interview questions

What's the difference between a forward proxy and a reverse proxy?

A forward proxy sits in front of clients and forwards their outgoing requests on their behalf; a reverse proxy sits in front of servers and forwards incoming requests to whichever backend should handle them.

Why would you put a reverse proxy in front of multiple backend servers?

So clients only need to know one address, while the proxy handles routing requests to the correct backend — hiding the internal architecture and making it easier to change.

Is a load balancer a type of reverse proxy?

Effectively yes — a load balancer is a reverse proxy whose specific job is distributing traffic across multiple identical backend servers.

What are common reasons an organization deploys a forward proxy for its own employees?

To filter or block access to certain sites, cache frequently requested content to save bandwidth, log outbound traffic for compliance, and hide the internal network's actual IP addresses from the sites employees visit.

How does a reverse proxy help with SSL/TLS termination?

The proxy handles decrypting incoming HTTPS traffic (and encrypting the response) at one central point, so individual backend servers don't each need to manage certificates and TLS handshakes — simplifying certificate management and offloading that CPU cost from the application servers.

Why might a reverse proxy cache static content before it even reaches the application server?

Content that rarely changes (images, CSS, JS bundles) can be served directly from the proxy's cache, which is much faster than re-running application logic on the backend for the same unchanged response every time.

What single point of failure risk does adding a reverse proxy introduce, and how is it usually mitigated?

If there's only one reverse proxy, its failure takes down access to everything behind it, even if the backend servers are fine — this is mitigated by running multiple redundant proxy instances behind something like DNS round-robin or a floating IP.

How does a reverse proxy enable zero-downtime deployments?

New versions of a service can be started alongside the old ones, and the proxy can gradually shift traffic to the new instances (and stop sending traffic to old ones) without ever exposing clients to an interruption, unlike replacing a single directly-exposed server in place.

What's the difference between a reverse proxy and an API gateway?

A reverse proxy's core job is routing and forwarding requests to the right backend; an API gateway builds on that with additional API-specific concerns like authentication, rate limiting, request/response transformation, and aggregating multiple backend calls into one client-facing response.

How does a CDN relate to the concept of a reverse proxy?

A CDN is essentially a globally distributed reverse proxy — it sits in front of an origin server at many geographic edge locations, caching and serving content from whichever location is closest to the requesting client, rather than routing to a fixed set of local backends.

Why does a reverse proxy typically add headers like X-Forwarded-For to the requests it forwards?

Once a proxy sits in the middle, the backend server would otherwise only see the proxy's own IP address as the request's source — X-Forwarded-For preserves the original client's IP so the backend can still do things like logging, rate limiting, or geolocation based on the real client.

What problem does the X-Forwarded-For header solve?

It solves the loss of the original client's IP address once a request passes through one or more intermediary proxies — without it, the backend would only ever see the last proxy in the chain as the apparent source of every request.

How can a reverse proxy implement rate limiting across an entire fleet of backend servers?

Because every request passes through the proxy before reaching any backend, the proxy can track request counts per client (by IP, API key, etc.) centrally and reject or throttle requests once a limit is exceeded — without each backend server needing to separately track and coordinate the same counts.

Describe a scenario where a system would use both a forward proxy and a reverse proxy at once.

A company's internal clients might go through a forward proxy to reach the internet (for filtering and logging outbound traffic), while requests coming into the company's own public-facing service pass through a separate reverse proxy that routes them to the correct internal backend — the two proxies serve entirely different directions of traffic.

Why might a company route its clients' outbound connections through a forward proxy for security reasons?

It gives the organization a single choke point to inspect, filter, or block risky outbound connections (like requests to known-malicious domains), instead of relying on every individual machine to enforce that policy independently.

What's a potential downside of routing all traffic through a single reverse proxy layer?

It adds an extra network hop (and thus a small amount of latency) to every request, and if not scaled or made redundant properly, it can become a bottleneck or outage point for the entire system, even when the backends themselves are healthy.

How does a reverse proxy decouple clients from changes in backend infrastructure?

Clients only ever address the proxy's stable, public endpoint; backend servers can be added, removed, resized, or moved without clients needing to know or change anything, since the proxy is the only thing that needs to be updated with the new routing details.

Why is it important for a reverse proxy itself to be highly available?

Every request to the system passes through it, so if the proxy goes down, clients lose access to every backend behind it — its availability effectively becomes the ceiling on the availability of the entire system.