Overview

X-Forwarded-For (XFF) is the de facto header that conveys the original client IP — hidden by reverse proxies and load balancers — to backend servers. It is the most widely used convention corresponding to the Forwarded standard's `for` parameter.

The value is a comma-separated list of IPs where, by convention, the leftmost is the original client and each entry to the right is a proxy the request passed through (e.g. `203.0.113.7, 70.41.3.18`).

Details

Behind a proxy the TCP source IP the server sees is the proxy's, so to use the real visitor IP for logging, rate limiting, or geolocation you need XFF. Each proxy builds the chain by appending the source IP of the connection it received to the right end of the list.

The biggest gotcha is spoofing. A client can send an arbitrary `X-Forwarded-For: 1.2.3.4` itself, so blindly trusting the leftmost value as the 'real client' exposes you to IP spoofing, rate-limit bypass, and access-control bypass. The safe rule is to trust only values appended by proxies you control: know how many trusted proxies you have, strip them from the right, and treat the first remaining (rightmost untrusted) entry as the real client.

In practice the outermost proxy should strip or reset any client-supplied XFF, and you register your CDN/LB IP ranges in your framework's 'trusted proxies' setting. If you're standardizing, consider migrating from XFF to Forwarded.

Syntax

X-Forwarded-For: <client>[, <proxy1>[, <proxy2>]]*

e.g. X-Forwarded-For: 203.0.113.7, 70.41.3.18, 150.172.238.178

Notes

• Never blindly trust the leftmost IP — a client can plant an arbitrary value at the front. 'Peel off as many trusted proxies from the right' is the safe rule.
• Rate limiting, access control, or fraud detection based on XFF alone can be bypassed by spoofing. Treat XFF from outside the trust boundary as an unverified hint only.
• Register CDNs/load balancers as 'trusted proxies' in your framework and sanitize externally supplied XFF at the outermost hop.

Related headers

Specification