Operations, proxies and overlooked details
Proxy trust, hop-by-hop fields and framing boundaries
Interpret clients and protocols safely behind a reverse proxy.
Understand the concept
A reverse proxy can terminate TLS and open another connection to the application. Forwarded fields can describe the original client, host and scheme, but only trust them from the configured proxy chain. An internet client’s spoofed forwarding field must not bypass limits or permissions.
Hop-by-hop fields apply to a connection rather than the entire end-to-end exchange. HTTP/2 and HTTP/3 do not accept every HTTP/1.1 connection convention. Parser disagreement about message boundaries can create request-smuggling risks. Reject ambiguous framing and maintain parsers across all hops; this lesson does not supply attack payloads.
Incorrect host or scheme interpretation can break callbacks, redirects and secure cookies. Configure trusted proxies and origin access for the deployment. IP addresses are not identities. Correlate gateway failures with request IDs and timings without logging raw credentials.
When diagnosing reverse-proxy, CDN and container deployments.
Unconditionally treating a client-supplied X-Forwarded-For as the real IP.
One topic. Three levels of depth.
Client → trusted proxy → APIThe API trusts forwarded information only from its configured proxy context.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
A user can submit any X-Forwarded-For value. Should you trust it?
Show the solution and explanation
Only trust configured proxy sources and the validated chain.No. Validate the source and proxy chain.