> X-Forwarded-For: 203.0.113.7, 198.51.100.2

TL;DR: X-Forwarded-For lists the client address followed by each proxy hop, but any client can forge it. Trust only the entries added by proxies you operate: configure the trusted proxies (nginx set_real_ip_from, Express trust proxy) instead of reading the leftmost value.

What is X-Forwarded-For?

The X-Forwarded-For (XFF) header records the address a request came from before it reached your server, because the TCP connection your server sees belongs to the nearest proxy. Each proxy appends the address of the peer it received the request from.

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178

Read left to right, that is: client 203.0.113.195, which went through proxy 70.41.3.18, whose address was seen by the last proxy 150.172.238.178. The last proxy’s own address is the socket peer and is not in the header. It is not standardised (MDN lists it as non-standard); Forwarded is the RFC 7239 replacement.

Why you cannot trust it by default

A proxy appends; it does not replace what the client sent. So a client that sends this directly:

curl -H 'X-Forwarded-For: 1.2.3.4' https://example.com/

reaches your app, behind one proxy, as X-Forwarded-For: 1.2.3.4, <real client IP>. The forged 1.2.3.4 is leftmost. Code that takes the first value now rate-limits, geo-blocks and audit-logs the wrong address, and an attacker can pick any IP to dodge a per-IP limit or to impersonate an allowlisted one.

Rule: start at the socket peer. If it is one of your proxies, step left one entry at a time while each entry is also one of your proxies. The first entry that is not yours is the client. Everything left of it is attacker-controlled text.

If no proxy sits in front of your origin, ignore the header entirely and use the socket address. If your origin is reachable directly (bypassing the CDN), every header is spoofable; lock the origin down to the proxy’s IP ranges.

Configure trusted proxies

nginx (ngx_http_realip_module, needs --with-http_realip_module, present in common distro builds). Without real_ip_recursive on, nginx takes the last address in the header; with it, nginx skips trusted addresses from the right:

set_real_ip_from 10.0.0.0/8;        # your load balancer / proxy ranges
set_real_ip_from 192.168.0.0/16;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

$remote_addr then holds the client address and $realip_remote_addr keeps the original peer. Log both while you debug.

Express. Count hops or name subnets; never use true on an internet-facing app, because it trusts the leftmost value:

// One reverse proxy (for example nginx or a single ALB) in front of Node
app.set('trust proxy', 1)

// Or name the proxy ranges
app.set('trust proxy', 'loopback, 10.0.0.0/8')

app.get('/ip', (req, res) => res.json({ ip: req.ip, chain: req.ips }))

With trust proxy unset, req.ip is the socket address, i.e. the proxy. The setting also controls req.protocol and req.hostname, so a wrong value affects secure-cookie and redirect behaviour as well.

Cloudflare. Cloudflare adds CF-Connecting-IP containing the single client address it saw, and appends to X-Forwarded-For. Use CF-Connecting-IP, but only if requests can reach you only through Cloudflare; otherwise a client can send that header too. Enterprise plans can also add True-Client-IP.

AWS ALB. The Application Load Balancer appends the connecting address to X-Forwarded-For by default, so the client-supplied part stays on the left. The ALB attribute routing.http.xff_header_processing.mode can be set to append (default), preserve or remove. CloudFront also appends the viewer IP, so behind CloudFront and an ALB there are two proxy hops to trust.

Kubernetes ingress-nginx. Controls live in the controller ConfigMap: use-forwarded-headers (trust inbound XFF, only when something you control is in front) and proxy-real-ip-cidr (which sources are trusted). With a cloud load balancer, externalTrafficPolicy: Local on the Service preserves the client source address.

Django. Django does not parse X-Forwarded-For for you: REMOTE_ADDR is the proxy. Either have the proxy layer rewrite it (nginx realip) or use a library that takes a trusted-proxy count, and never read request.META['HTTP_X_FORWARDED_FOR'] raw.

Logging and gotchas

• Log the full header plus the socket address. The socket address is the only value the client cannot forge.
• The header can contain IPv6 addresses, ports in some proxies (1.2.3.4:5678), and the string unknown. Parse and validate before using it as a key.
• Values are comma separated and the header may appear as several separate header lines; treat them as one comma-joined list.
• Do not use XFF alone for authorization. An IP allowlist that trusts a header you did not verify is a bypass.

Related Headers

• Forwarded - the standard alternative
• X-Forwarded-Proto - original scheme
• Via - proxies in the path
• Host