Reverse proxy debugging · RFC 7239 · X-Forwarded-*

Forwarded Header Builder & Proxy Chain Inspector

Build canonical Forwarded headers, inspect legacy X-Forwarded-* values, model trusted proxy hops, and generate production-ready snippets for Node, Nginx, and edge environments.

1) Build a proxy chain

Add one or more hops. The first row represents the client-facing proxy entry.

1 hop configured

Client IP / for Use unknown, obfuscated IDs, IPv4, or bracketed IPv6. Proxy IP / by Optional in real deployments, but useful for diagnostics. Original host Protocol

Quote IPv6 / special tokens safely Generate matching X-Forwarded-* headers

2) Generated headers

Canonical output plus copyable legacy equivalents.

Forwarded header

Legacy headers

curl debug snippet

3) Inspect an incoming proxy chain

Paste raw headers and choose how many rightmost proxies are trusted.

Trusting 1 proxy

Raw Forwarded header Raw X-Forwarded-For chain

X-Forwarded-Proto X-Forwarded-Host Trusted proxy hops from the right

Prefer RFC 7239 Forwarded when present Flag private/reserved address ranges

Inspector summary

Advice

#	Hop source	Address / token	Trusted?	Notes

Implementation snippets

Safe defaults beat blindly trusting every hop.

Node / Nginx / Cloudflare starter snippets

When to trust these headers

Only trust forwarding headers from proxies or CDNs you actually control.
Rightmost entries usually represent the nearest upstream proxies; count trust from the right, not the left.
If untrusted clients can connect directly to the app, they can spoof X-Forwarded-For and Forwarded.
Forwarded is standardized, but many stacks still rely on legacy headers. Handle both when debugging.
Prefer explicit allowlists or exact hop counts over trust proxy = true in production.

Quick checks

Support the toolbox

If this saved you a debugging session, fuel the next weirdly specific utility.

Buy Me a Coffee