X-Forwarded-For demo Help on interpreting the XFF data

When handling requests, you are likely to come across several different possible scenarios when looking at the IP address section. This page aims to guide you through what the tool is trying to tell you.

When the tool receives a request from a newbie, the tool records the newbie's IP address as seen by the server on which ACC runs. However, there is sometimes a proxy between the tool and the newbie - when that is the case, the IP address seen by the server is that of the proxy, not the newbie. Some proxy servers include a special header, known as X-Forwarded-For, in which they append the IP address of the end user to this header before passing the request on. If there are multiple proxy servers, multiple IP addresses get added to this header.

If there is no proxy server, this is what you would see:

This scenario, however, is not likely to ever appear for the simple reason that Wikimedia Cloud Services have placed their own proxy server in front of the tool. Thus, there will always be at least one proxy server.

97% of requests: Wikimedia proxy only

When there is only the WMCS proxy in place, this is what you are likely to see something more like this:

The above scenario has passed through one server we trust (172.16.0.164), and that server has indicated it received a request from 190.0.2.1. At this point, the XFF chain stops, and we assume that 192.0.2.1 is the client's IP address.

We also augment each IP address with some extra information, including the estimated location of the IP address, and the reverse DNS name of the IP address. These can help give some indication of the type of IP address - whether it's a residential ISP, a hosting provider, or otherwise.

2% of requests - another trusted proxy

Occasionally, we will get a request from a user who is using a proxy service which we trust to provide accurate XFF headers. It's worth noting here that Wikimedia takes the XFF headers as truth where the provider of the XFF header is trusted. We use the same trust list here, but we display all the data anyway. The essence of it is that the last "trusted" IP address in the list will be the one that Wikimedia uses.

In this example, the user has passed through a trusted proxy provider before hitting the WMCS proxy. Both proxy servers are listed and marked as trusted, and we don't show the IP links for those trusted proxy servers.

0.5% of requests - untrusted proxies

Conversely to the above, sometimes people will request an account from a proxy server which publishes the client IP address, but not one that we trust to be accurate.

As each server on the chain of proxies has the option to rewrite the entire XFF header, we should not use any entries from servers we don't trust. If we trust a server to not forge the XFF header, we can trust the next item in the chain is accurate, but no further. It is at this point that the trust chain breaks, and we start seeing lots of red flags.

In this scenario, because we trust the first IP address, we can believe that it's correct in telling us that 198.51.100.234 is indeed where the request has come from. However, we cannot trust that server is telling the truth.

The second server is reporting that the third server exists, but Wikimedia will only believe that the client is on the second IP address, and so this is the IP address we should check. It is worth checking the third too, because it's possible that the trust lists between ACC and Wikimedia have drifted.

0% of requests - an insane possibility

If someone really wants to play with the XFF headers, they are welcome to do so as they send in the request. If they're putting crazy things in the header, it's not outside the realm of possibility that something like this will occur:

This example has three trusted servers - 172.16.0.164, 198.51.100.123, and 198.51.100.124. However, this indicates the breaking of the trust chain - because the request passed through an untrusted server, we can't tell if the untrusted server is forging the information leading to the trusted server. As such, we indicate that the 198.51.100.124 would be trusted, had the trust chain not already been broken.

In this case, the IP address that Wikipedia will see is 198.51.100.234 - the first untrusted IP address in the list.