Name: System Design Masterclass
Availability: InStock

The previous lesson's worked for the client. This one works for the servers, and it is deployed by the people who run them.

The purpose is not primarily security or speed. It is indirection: clients hold one address, and everything behind that address becomes free to change.

An isometric diagram with one tall gateway block on the left and six backend blocks on the right, one of them noticeably shorter than the others. Text on the left reads one address, one certificate, one DNS record. Text on the right reads any number behind, added, removed, restarted, replaced, without telling anyone. A line beneath reads that the client never learns that any of this happened, which is the entire product. — IsometricFigure 1. One stable front door, and everything behind it free to change
Clients resolve one name, so , certificates and firewall rules all have exactly one target.
One of the blocks in that picture is being restarted, and nobody outside can tell. That is what makes deploys, scaling and failover possible without coordinating with anybody.

Every other feature in this lesson, TLS termination, load balancing, caching, , is something you can only do once there is a single place that sees every request. The front door comes first and everything else is built on it.

The most consequential thing about a reverse is what it does to the backend's view of the world, and it is almost never drawn.

A sequence diagram with three lifelines: a client at 203.0.113.44 over TLS, the reverse proxy, and a backend. The client sends GET /api/users over https. The proxy sends GET /api/users over plain http, noted as the connection coming from the proxy so the backend's peer is the proxy. The proxy adds X-Forwarded-For with the client's address, noted as the only way the backend learns who the client was. The backend returns 200 with no idea TLS was involved. — SequenceFigure 2. The backend's idea of the client is whatever the proxy told it
The connection genuinely comes from the proxy, so every fact about the original request arrives in a header that the proxy chose to add.
If the proxy does not add them, the backend simply does not know.

That is easy to check, because a reverse proxy is a short program.

A recorded terminal session. One proxy on port 8801 with two backends on 8811 and 8812. Four curls alternate: served_by 8811, 8812, 8811, 8812. Then what the backend can see about the client: peer 127.0.0.1, marked as the proxy rather than the client; X-Forwarded-For 127.0.0.1, marked as a header the proxy chose to add; X-Forwarded-Proto https, marked as the client used TLS while this hop did not. One backend is then taken out with a control command, and the next three requests all report served_by 8812. — RecordedFigure 3. A real proxy, two backends, and one taken out mid-run
The middle block is the part worth reading twice. The backend's own view of who connected is the proxy, every time, and the client's identity is a header.
When a backend is removed, the client changes nothing and notices nothing.

Two bugs follow directly from this, and both are common. or geo-blocking on the peer address limits the proxy, not the client. And building a redirect from the scheme the backend saw produces an http:// URL for a user who arrived over https.

A table of five headers. X-Forwarded-For carries the client's address, and is a list if there is more than one proxy. X-Forwarded-Proto carries http or https so the app can build correct absolute URLs. X-Forwarded-Host carries the name the client used, which is not the Host the backend receives. Forwarded carries all of the above standardised in RFC 7239, and is far less widely used. X-Real-IP carries the client's address again and is an nginx convention rather than a standard. A note explains that all of these are ordinary headers so anything that can reach a backend directly can forge them. — FigureFigure 4. Everything the backend knows arrives in a header it must be told to trust
Four of these are conventions rather than standards, which is why every web framework has a setting for which one to read and how many hops to trust.
None of them is authenticated in any way.

The security rule is short: strip these headers at your outermost proxy and set them yourself. If you append to whatever arrived, a client can put anything it likes at the front of the list and your rate limiter will believe it.

Where this shows up in interviews

Where this shows up in interviews

Reverse Proxy

The rest of this lesson

Continue this lesson

One Front Door, and Everything Behind It Free to Move

What the Backend Actually Receives