X-Forwarded-For

X-Forwarded-For is a de facto request header in which a proxy records the address of the client it received the request from. It is not defined by any RFC. RFC 7239 standardised the same idea under the name Forwarded, and notes that the older header is nonetheless widely used.

#The two spellings

X-Forwarded-For: 203.0.113.7, 198.51.100.9
Forwarded: for=203.0.113.7;proto=https;by=198.51.100.9

Each intermediary appends the address it saw, so the list grows left to right and the leftmost entry is the furthest from your server. RFC 7239 also gives Forwarded a way to carry the protocol and the receiving interface, which the older header never had.

#Why the leftmost value is not the client

Any entry can be forged, because the client can simply send the header itself and a naive intermediary will append rather than replace. Only the entry added by an intermediary you operate is trustworthy. Counting from the right, discard as many entries as you have proxies you control, and treat everything beyond that as claimed rather than observed.

Using an unvalidated leftmost value for rate limiting, access control or logging is the standard way to build a limit that anybody can step around.

#What a proxy provider does with it

Some proxies add the header, some pass it through, some strip it. The categories sold as transparent, anonymous and elite describe this behaviour, but the labels are marketing terms with no specification behind them, so the only reliable answer is to test the endpoint you bought against a service that echoes the headers it received.

Test with the exact protocol you will use in production. A proxy can behave differently for plain HTTP and for CONNECT, because in a tunnel it has no request to edit.

#Commonly confused with

Via is standardised and records which intermediaries handled the message and on which protocol version. It is about the path. X-Forwarded-For is about the origin of the request. A proxy may send both, either, or neither.