X-Forwarded-* Header Reference
Reference for X-Forwarded-For, -Host, -Proto and the RFC 7239 Forwarded header.
Overview
The X-Forwarded-* Header Reference documents the four de-facto proxy headers — X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Port — alongside the IETF-standard Forwarded header (RFC 7239) that supersedes them. Each entry describes what the header carries, who appends to it, and how to trust it safely.
Useful for backend developers and ops engineers learning how to read X-Forwarded-For behind a load balancer or how to trust proxy headers safely. Reach for it implementing rate limiting, geolocation, audit logging, or anywhere your application needs to know the original client's IP and scheme behind one or more reverse proxies.
How it works
Reverse proxies (Cloudflare, nginx, ALB, CloudFront) mutate or strip the original request's metadata, so they add the original values into headers the application can read. X-Forwarded-For is a comma-separated list of IPs (closest proxy last); X-Forwarded-Host and -Proto carry the original host and scheme. The standardised Forwarded header packs all of them into a single structured field per RFC 7239: for=192.0.2.1;proto=https;host=example.com.
The critical security note: never trust these headers blindly. Configure your edge so only the trusted proxy can set them, and strip any inbound copies on the very first hop. Otherwise an attacker can spoof their source IP.
Examples
X-Forwarded-For: 198.51.100.7, 10.0.0.5— original client198.51.100.7, last proxy10.0.0.5.X-Forwarded-Proto: https— original request used HTTPS, terminated at the load balancer.Forwarded: for=198.51.100.7;proto=https;host=example.com— RFC 7239 single-header equivalent.X-Forwarded-Host: example.com:443— original host as seen by the client, including non-default port.
FAQ
Which IP is the real client in X-Forwarded-For?
The leftmost IP that you trust the source of. Walk the list right-to-left, skipping IPs you control (your proxies). The first non-trusted IP is the closest you can attribute to the actual client.
X-Forwarded-For or Forwarded?
Both. Implementations support X-Forwarded-For widely, while Forwarded is the IETF standard. Some proxies emit one but not the other. Read both, prefer Forwarded when present.
How do I trust these headers safely?
Restrict acceptance to specific upstream IPs (your load balancer/CDN ranges), and strip any inbound copies before your proxy appends. Frameworks like ASP.NET Core, Express's trust proxy, and Nginx's set_real_ip_from handle this.
What if the request bypasses the proxy?
If your origin is directly reachable, an attacker can hit it with any forged headers. Always firewall the origin to allow only the trusted proxy IPs and reject direct connections.