Proxy vs reverse proxy

For this lesson, we'll focus on what each kind does, how it changes what your app sees (client IPs especially), and the failures that show up as 502s and 504s. Interviewers like it because nearly every design has a reverse proxy in it, often under another name, and they want to know you understand what that box does.

01Picture it first: same box, opposite sides

The software can be identical (nginx, Envoy and HAProxy can play either role). What changes is which side it guards. Here are both, side by side.

Notice three things:

• The client chooses a forward proxy. Laptops are configured (or forced by the network) to send traffic to it. Websites never asked for it.
• The server owner chooses a reverse proxy. Clients have no idea it exists; DNS for api.example.com points at it.
• Both break the end-to-end connection. There are two TCP connections, client to proxy and proxy to server, which is exactly why the backend loses the client's IP.

02The forward proxy: controlling what leaves

Forward proxies show up in interviews less often, but one case is worth knowing cold: your servers calling URLs that someone else chose. Webhooks and "import from URL" features let a user point your backend at an address like http://10.0.0.12:6379/ and probe your private network. That's server-side request forgery (SSRF).

The fix is an egress proxy that every outbound call must use. Stripe open-sourced theirs: Smokescreen carries most of Stripe's outbound traffic, including webhooks, checks hostnames against an allow-list and refuses to connect to internal addresses. The other classic uses:

• Corporate egress: one controlled exit to the internet, with logging and content filtering.
• Allow-lists for partners: a partner whitelists one stable egress IP instead of your whole autoscaling fleet.
• Privacy: the destination sees the proxy's address, not the client's.

03The reverse proxy: the front door of almost every design

A reverse proxy earns its place by doing work once, at the edge, so every app server doesn't have to.

Buffering is the one candidates forget, and it's the most "under the hood" item on the list. nginx buffers both directions by default: proxy_request_buffering and proxy_buffering are both on. With request buffering, the entire body is read from the client before nginx sends anything upstream, so an app worker isn't held for the 20 seconds a mobile client takes to upload a form.

04What the app sees: X-Forwarded-For and Forwarded

Here's the catch with two TCP connections. The app's socket says the request came from the proxy, so anything that needs the real client (rate limits per IP, geo-blocking, fraud signals, audit logs) reads a header the proxies add. The de facto one is X-Forwarded-For; RFC 7239 standardises the same idea as Forwarded: for=203.0.113.7;proto=https;by=198.51.100.4. Each proxy appends the address it received the connection from, so the list grows left to right.

The rule I use: trust the header only as far as your own proxies wrote it. Start at the right end, skip every address that belongs to a proxy you control, and the first one left is the client. Taking the leftmost entry is the classic bug: an attacker sends X-Forwarded-For: 192.0.2.66 and suddenly every request "comes from" a fresh IP, which walks straight past a per-IP rate limiter.

You rarely parse this by hand. nginx's realip module does it with set_real_ip_from (the CIDRs of your trusted proxies) plus real_ip_recursive on, which picks the last non-trusted address. In Spring Boot, one property makes the embedded server honour the headers, so redirects, request.getRemoteAddr() and generated links use the client's view:

# application.properties: trust X-Forwarded-* / Forwarded from the proxy in front
server.forward-headers-strategy=native

Only turn this on when the app is reachable solely through your proxy. If clients can hit the app directly, they can set the header themselves.

05Sidecars and service mesh: a proxy next to every service

So far the proxy sits at the edge. Inside a microservice system, the same idea moves next to each service. Envoy describes itself as an L7 proxy designed to run alongside every application server: the app talks to localhost, and its local Envoy handles service discovery, load balancing, retries, timeouts, mTLS and metrics on the way out. Put one beside every instance, add a control plane that pushes config to all of them, and you have a service mesh (Istio and similar products use Envoy this way).

The trade-off: the same network behaviour in every language, paid for with an extra local hop on each side of every call and a fleet of proxies to run. A mesh is worth proposing once you have dozens of services in several languages; for five services, a shared client library is simpler. Service discovery covers how sidecars find each other.

06Reverse proxy vs load balancer vs API gateway vs CDN

These four overlap, and one product can play several roles at once. Treat them as one family with different emphasis.

My one-liners: every L7 load balancer is a reverse proxy; an API gateway is a reverse proxy that knows your customers; a CDN is a reverse proxy spread across the planet.

07A minimal reverse proxy config, with timeouts

Here's a short nginx config for that service. Without these lines, nginx's defaults are 60 seconds for proxy_connect_timeout, proxy_read_timeout and proxy_send_timeout, and a 1 MB client_max_body_size (larger bodies get 413).

upstream orders_api {
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
    keepalive 32;                              # reuse warm connections to the apps
}

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/nginx/tls/api.crt;
    ssl_certificate_key /etc/nginx/tls/api.key;
    client_max_body_size 2m;

    location /orders/ {
        proxy_pass http://orders_api;
        proxy_http_version 1.1;
        proxy_set_header Connection "";        # needed for upstream keepalive
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_connect_timeout 2s;              # a healthy backend accepts in ms
        proxy_read_timeout    5s;              # ~6x the p99, not 60 s
        proxy_send_timeout    5s;
    }
}

Notice that proxy_read_timeout isn't a limit on the whole response. nginx documents it as the gap allowed between two successive reads, so a backend that trickles a byte every 4 seconds never trips it. If you need a hard deadline per request, enforce it in the app as well.

08Failure modes: what breaks and why

The last row is documented by AWS for its Application Load Balancer: if the application's idle timeout is shorter than the load balancer's (60 seconds by default), the load balancer can send a request on a connection the app just closed and return 502 Bad Gateway to the client. It's the most confusing 502 there is, because nothing is actually down.

Both codes come from RFC 9110: 502 Bad Gateway means a proxy got an invalid response from upstream (proxies also use it when the upstream refuses or resets the connection), and 504 Gateway Timeout means no response arrived in time. A 503 usually means nothing healthy was available. So 502 sends me to "is the upstream up and speaking HTTP?", and 504 to "what is the upstream waiting on?".

09How it shows up in design problems

• Design a webhook delivery service: outbound calls go through a forward egress proxy that blocks private IPs and gives customers one stable IP range to allow-list.
• Design an LLM gateway: a reverse proxy in front of model providers, with response buffering off so tokens stream, and read timeouts long enough for slow generations.
• Design Dropbox / Google Drive: large uploads shouldn't be buffered through the proxy at all; hand out presigned URLs to object storage.
• Design a rate limiter: the limiter often runs in the reverse proxy, and limiting per IP only works if you extract the client IP from trusted hops.

At this point, you should ask your interviewer whether the API is public or internal. A public one needs TLS, a WAF and real-client-IP handling at the edge; an internal one may only need a sidecar or a load balancer.

10Interview follow-ups

What if the backend needs the client's real IP?

The proxy appends it to X-Forwarded-For or Forwarded, and the app reads it from the right, skipping its own proxies' addresses. For non-HTTP traffic through an L4 balancer, the PROXY protocol prepends the original address to the TCP stream. Either way, the app must not be reachable except through the proxy.

What if TLS is terminated at the proxy: is the traffic behind it unencrypted?

It can be, and inside one private network many teams accept that. If you're handling payments, health data or a zero-trust network, re-encrypt from proxy to app, usually with mTLS so each side proves who it is. The cost is extra handshakes, which keepalive pools mostly hide.

What if users report random 502s but every server looks healthy?

I'd check idle timeouts first: if an app closes idle keepalive connections sooner than the proxy, the proxy occasionally sends a request down a dead connection. Then check deploys, since a backend killed without draining resets in-flight connections. The access log's upstream status and upstream address fields usually tell you which hop failed.

11How to say it in the interview

When I ask about proxies, I'm listening for three things: that you can say whose side each proxy is on, that you know what the reverse proxy box actually does (not "it forwards requests"), and that you know what it breaks, especially client IPs and timeouts.