X-Forwarded-For

The originating IP address of a client request.

Fastly reads this header from requests and writes it into requests. It is defined by an external standard.


This is a companion discussion topic for the original entry at https://developer.fastly.com/reference/http/http-headers/x-forwarded-for

Summarising the table above it seems like the X-Forwarded-For header received by the origin server is made up of:

{clientValue}, {clientIP}, {edgeIP}

Where:

  • {clientValue} is the value of any existing X-Forwarded-For header present on the request when it is received by Fastly. If present, this is always preserved
  • {clientIP} is the IP address of the client as seen by Fastly. This is added if the client connects to Fastly over TLS.
  • {edgeIP} is the IP address of the Fastly server that initially handles the request. This is only added if the client connects to Fastly over TLS, and Fastly connects to the origin over TLS, and shielding is enabled.

The most likely scenario seems to be that most Fastly services will forward an XFF header to origin with one value in it, which will be the client IP.

The most common problem I’ve noticed with this header is origin server software assuming it only contains a single IP address.