Networking & Protocols

What reverse proxies do

Crux A reverse proxy sits invisibly between clients and backends — it completes the client connection, picks a backend, and forwards the request, decoupling scaling from client visibility.

Your altitude — climbing toward senior

ZeroJuniorMiddleSenior

You are at junior altitude — the surface

◷ 8 min

You click a link and connect to what feels like a single server — but behind that address, dozens of machines are waiting to handle your request. Something invisible decided which one served you, and you will never know which it was.

The hidden intermediary

A reverse proxy sits between clients and a pool of backend servers. Clients connect to the proxy believing it is the real server. The proxy:

Completes the TCP (and TLS) handshake with the client.
Picks a backend from its pool.
Opens a separate TCP connection to that backend.
Forwards the client’s request to the backend.
Waits for the backend’s response and relays it back to the client.

The client never sees the backend’s IP address or knows how many backends exist. This is the defining property: the client talks to one address; the proxy talks to many.

Why two connections instead of packet-forwarding

A dumb packet forwarder (layer 3 NAT) passes packets unchanged — it cannot inspect or modify the payload. A reverse proxy that routes on HTTP must parse the request to decide where it goes. Parsing requires owning both sides of the conversation: the client-side TCP connection (to read the request) and the backend-side TCP connection (to write it out).

This two-connection model is what makes the proxy both powerful and visible to each side. The backend sees the proxy’s IP, not the client’s — a concern addressed in the next lesson.

The restaurant metaphor

A restaurant with one host (the load balancer) and multiple chefs (the backends). When a customer (client) arrives the host decides which chef is least busy, passes the order, and returns the dish to the customer. Customers never talk to chefs. If a chef calls in sick, the host stops sending orders to that station — seamlessly.

Reverse proxy basics

Client connections seen by client: 1 (to the proxy IP)
TCP connections per request (L7 proxy): 2 (client→proxy + proxy→backend)
Backends visible to the client: 0 (proxy hides them all)
Health check interval (typical): 10–30 s
Backends a single nginx can front: hundreds
Deployment zero-downtime: drain + swap: yes, via health check + draining

What happens when a backend crashes

The proxy’s health-check loop probes every backend on a fixed interval (10–30 s). After 2–3 consecutive failures, the backend is marked unhealthy and new requests are no longer routed to it. In-flight requests on the still-open connection either complete or timeout. When the backend recovers, it is added back after 2–3 consecutive successes.

This means:

Clients are routed only to healthy backends.
A backend crash is invisible to new clients within one health-check interval.
Active connections to the crashed backend still fail — the proxy cannot resurrect a TCP connection that died.

Why this works

Why a forward proxy is different. A forward proxy (like a corporate web filter) sits on the outbound path: the client knows about it and connects to it intentionally. A reverse proxy sits on the inbound path: the client is unaware of it and thinks it is talking to the origin server. Forward proxies enforce client policy; reverse proxies enforce server-side scaling and resilience.

Quiz

Why does a reverse proxy open TWO separate TCP connections instead of forwarding packets directly to the backend?

Quiz

A backend crashes mid-request. What does the load balancer do for the NEXT client request that arrives?

Order the steps

Order the sequence when a client makes a request through a load balancer:

1 Client establishes TCP connection to the load balancer
2 Client sends HTTP request to the load balancer
3 Load balancer picks a healthy backend
4 Load balancer opens a TCP connection to that backend
5 Load balancer forwards the client's request to the backend
6 Backend processes the request and sends a response
7 Load balancer forwards the response back to the client

Complete the analogy

A load balancer is like a restaurant _______ who seats guests and directs orders to the kitchen.

Recall before you leave

01
Why does a load balancer need to detect backend health?
02
What is the key difference between a forward proxy and a reverse proxy?
03
Why does a reverse proxy open two TCP connections per request rather than forwarding packets at layer 3?

Recap

A reverse proxy acts as the public face of an entire backend pool: clients connect to one IP, the proxy picks a healthy backend, opens its own connection to that backend, and shuttles traffic between the two. Two TCP connections per request are the price of being able to parse and route HTTP. Health checks run in the background every 10–30 seconds; after 2–3 failures a backend is removed from the pool and traffic is immediately redistributed. This decoupling — clients talk to one address, backends are swapped freely — is what makes zero-downtime deployments and backend scaling invisible to users.

Connected lessons

deepens into

appears again in258

Continue the climb ↑Balancing algorithms: round-robin to power-of-two-choices