Reverse proxy: an explicit intermediary and trust boundary

A reverse proxy is an HTTP gateway on the origin side: clients connect to the proxy, and the proxy dials selected upstreams. That creates separate transports and an explicit trust, retry, buffering, caching, identity, and observability boundary.

Mental model

• The client never has a physical application connection directly to an origin hidden behind the proxy in this model.
• TLS can terminate at the proxy, pass through as a tunnel, or be established again to the upstream. Each choice changes visibility and authentication.
• Forwarded metadata is optional and forgeable unless a trusted proxy sanitizes the incoming chain and the origin trusts only configured hops.
• Load balancing, caching, WAF policy, authentication, compression, and retries are independent features, not automatic properties of every reverse proxy.

Гарантии и границы

• A gateway-generated 502 or 504 describes an intermediary outcome, not a unique root cause.
• Automatic retry of non-idempotent requests is unsafe unless the proxy knows application semantics or can prove the request was not applied.
• Shared cache reuse must respect HTTP cache keys, authorization, freshness, Vary, and validation.
• Buffering can make request replay possible before upstream send, but once streaming has begun the outcome can become ambiguous.

Сценарии диаграммы

Terminate, sanitize, authorize, and route. The proxy accepts the client connection, creates a separate upstream connection, and owns the translation boundary.

Shared cache with validation. A reverse proxy can answer from a shared cache only when HTTP caching rules permit reuse for this request.

Retry safety depends on method, body state, and outcome. The proxy can retry some failures only while HTTP and application semantics make replay safe.

Forwarded metadata trust boundary. Clients can forge forwarding fields; the trusted edge must remove or overwrite untrusted values before adding its own element.

Streaming and backpressure. Request or response buffering changes memory, latency, retry options, and slow-client isolation.

Архитектурные решения

• Document client and upstream protocol, TLS identity, Host or authority rewrite, forwarding metadata, and timeout ownership.
• Use bounded retry budgets tied to remaining deadline and method/application idempotency.
• Choose buffering per route from inspection, memory, disk, latency, cancellation, and retry needs.

Сбои и неоднозначные исходы

• Proxy health can hide origin saturation until queues and retries amplify load.
• A slow client or origin can consume proxy buffers; backpressure and hard limits are mandatory.
• Canary weights do not guarantee exact request percentages for small samples or sticky/long-lived connections.

Операционный checklist

• Strip hop-by-hop fields correctly and prevent request smuggling through consistent parsing.
• Trust forwarding fields only from an explicit proxy chain.
• Bound headers, body, decompression, buffers, retries, connections, and timeouts.
• Test upstream TLS failure, partial body, slow client, cache poisoning, origin drain, and retry storms.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc9110.html
2. https://www.rfc-editor.org/rfc/rfc9111.html
3. https://www.rfc-editor.org/rfc/rfc7239.html
4. https://nginx.org/en/docs/http/ngx_http_proxy_module.html
5. https://nginx.org/en/docs/http/load_balancing.html