Nearly every production backend sits behind a reverse proxy, whether that's Nginx, Envoy, or a managed cloud proxy like an ALB or API Gateway — it's the component that decides what the outside world sees: Internet → Reverse Proxy → Backend. Confusing it with a forward proxy, or with a plain load balancer, is a common interview stumble, and interviewers will specifically probe "whose traffic is being proxied, on whose behalf" to check you actually understand the distinction rather than having memorized it.
A reverse proxy is a server that sits in front of your actual application servers and handles every incoming request on their behalf. Visitors never talk to your real servers directly — they talk to the reverse proxy, which then decides which backend server should handle the request, forwards it, and sends the response back. From the outside, the whole operation looks like a single server, even if there are dozens behind it.
Think of a large restaurant with a host stand at the front door. Guests never walk straight into the kitchen or pick their own table — they talk to the host, who decides which table and which server handles them based on who's free. From the guest's point of view, there's just one restaurant; behind the scenes, the host is quietly routing traffic to whichever staff member can handle it.
The single fact that resolves almost every confusion here: a forward proxy is deployed on behalf of the client, a reverse proxy is deployed on behalf of the server. The client, in a forward proxy setup, knows it's using a proxy and configures it explicitly (corporate egress proxy, VPN, an anonymizing proxy). The server on the other end has no idea a proxy was involved — it just sees a connection from the proxy's IP. In a reverse proxy setup, it's the opposite: the client has no idea it's not talking directly to "the server" — from the client's point of view, the reverse proxy IS the server. The proxy is configured and controlled by the operator of the backend, not the client.
Forward proxy (proxies traffic OUT, on behalf of the client):
[Client] --> [Forward Proxy] --> Internet --> [Origin Server]
Server sees the proxy's IP, not the real client's.
Example: corporate network egress filter, VPN.
Reverse proxy (proxies traffic IN, on behalf of the server):
[Client] --> Internet --> [Reverse Proxy] --> [Backend Server(s)]
Client sees the proxy as if it WERE the server.
Example: Nginx/Envoy/ALB in front of your microservices.Both are "a server that relays requests," which is exactly why people conflate them — the difference is entirely about which party (client or server) the proxy is deployed to protect and represent.
# See the proxy identify itself — many reverse proxies add a Via or
# Server header revealing themselves (Nginx, cloudflare, etc.)
curl -sI https://example.com/ | grep -i "server\|via\|x-cache"
# Watch TLS termination happen at the proxy: the cert you see belongs
# to the proxy/edge, not necessarily to whatever backend served it
openssl s_client -connect example.com:443 -servername example.com /dev/null | openssl x509 -noout -issuer -subject
# Compare response headers for a static asset (likely proxy-cached)
# vs a dynamic API response (likely passed straight through)
curl -sI https://example.com/static/app.js | grep -i cache
curl -sI https://example.com/api/health | grep -i cache
# Locally: run nginx as a reverse proxy in front of a toy backend to
# see routing config directly
docker run --rm -p 8080:80 -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro nginxQ: What's the difference between a reverse proxy and a load balancer?
A: A load balancer's job is narrowly traffic distribution across multiple backend instances. A reverse proxy's job is broader — it can do TLS termination, caching, compression, auth, and routing, and it may or may not also load-balance. In practice the line is blurry because tools like Nginx and Envoy do both at once: they're reverse proxies that also load-balance across the backends they route to. The useful distinction to state in an interview is "load balancing is a specific responsibility; reverse proxying is a broader role that often includes load balancing."
Q: Why would you use a forward proxy at all — what's a real use case?
A: Corporate networks route employee traffic through a forward proxy to enforce content filtering, log outbound traffic for compliance, or funnel everything through a small set of egress IPs that can be allow-listed by third parties. VPNs are also effectively forward proxies from the client's perspective — the client explicitly opts into routing traffic through an intermediary.
Q: What security benefit does a reverse proxy provide beyond routing?
A: It hides backend topology (internal IPs, service count, internal architecture) from the internet — attackers only ever see the proxy. It's also a single place to enforce TLS versions/ciphers, apply WAF rules, and rate-limit or block abusive clients before they ever reach application servers, rather than needing every backend service to implement that defense itself.
Any "design an API gateway" or "design a scalable web architecture" question expects a reverse proxy layer between the internet and your services — it's usually the first box you draw after the client. When asked to add authentication, rate limiting, or TLS to a system that doesn't have it yet, "push it into the reverse proxy/gateway layer" is frequently the expected answer instead of adding it to every service individually. It's also the natural place to mention when discussing zero-downtime deploys (the proxy can route around an instance being redeployed) and canary releases (the proxy routes a percentage of traffic to a new version).
A reverse proxy adds a hop of latency and becomes a component that must itself be scaled and secured — it can become a single point of failure if not deployed redundantly — but it consolidates TLS, caching, and routing logic in one place rather than duplicating it across every backend service. Interview gotcha: a reverse proxy is not the same thing as a load balancer — a reverse proxy's job is broader (protocol handling, caching, security, compression), while a pure load balancer's job is just traffic distribution; in practice, tools like Nginx and Envoy do both at once.