← Back to Labs

Reverse Proxies

Trace how a reverse proxy terminates the public request, selects an upstream, preserves identity, reuses connections, and decides whether retrying is safe.

Request
Backend
Classic idempotent API read
Small JSON request
Primary backend is healthy and selectable.
ClientAthens browserGET /v1/orders/42api.example.euReverse proxypublic TLS, routing, buffering, retry policySNI: api.example.euALPN: h2 on the public sideroute -> api_poolGET /v1/orders/42headers and policy prepared for upstreamweb-aSSR or app tieridle peerapi-aprimary APIselected upstreamapi-bstandby or peer APIidle peerPublic side: TLS 1.3 + HTTP/2 for api.example.euRequest is flowing normally through the proxy.
Route decision
api.example.eu/v1/orders/42 -> api_pool -> api-a
Chosen upstream
api-a · primary API
No special backend action in this scenario.
Upstream request headers
GET /v1/orders/42 HTTP/1.1
Host: api.internal.svc
X-Forwarded-For: 203.0.113.44, 10.20.0.15
X-Forwarded-Host: api.example.eu
X-Forwarded-Proto: https
X-Request-Id: rp-7f3a19c2
Step 1 / 5The public TLS session ends at the reverse proxy

The browser connects to the proxy, not directly to the app. That gives the proxy the certificate, the public hostname, and the first chance to accept or reject the request.

Arrow keys to navigate · R to reset

Tap dots to jump to any step

Read the full article →Take the quiz →