As designed XenForo not logging the real IP when user is browsing with Chrome's "Data Saver" enabled


Well-known member

Chrome mobile comes with a functionality called "Data Saver":

When you're using Data Saver, Google's servers reduce the amount of data that gets downloaded when you visit a webpage. How much data gets saved depends on the type of content on the page. Secure pages (pages that start with https) and incognito pages load without any data savings.

With Data Saver turned on:
  • Some websites might not be able to accurately determine your location
  • Some images might look a little fuzzy
  • Internal websites, such as your company’s intranet sites, might not load
  • Sites that your mobile carrier uses to authenticate and bill you might behave unexpectedly. For example, you might have trouble logging in to your mobile phone provider's website.

When you enable this feature, basically your IP changes because you're now browsing using Google as a proxy. This will make XF to record the Google IP (something like instead of the real IP of the member causing a lot of problems with the Shared IPs tool.

Why I'm reporting this as a bug? Because if you use a service like What is my IP it will recognize and display your real IP, not the Google IP.

The same problem applies when using Opera Mini (which comes by default -I think- with a similar functionality of Chrome's Data Saver). I however have not been able to see if What is my IP recognizes your real IP or the IP assigned by Opera.



Well-known member
As an example, the previous post was posted with Data Saver disabled and this one is being posted with Data Saver enabled.

Compare the IPs.

Edit: after reading Optic's answer please note that post #1 was posted using my Wi-Fi connection while post #2 through my 3G so in case what he said is true then please don't get confused when you see that IPs are different.
Last edited:


Well-known member
I "think" that is normal. Google Data Saver will not work for websites that are HTTPS. Looking at "What is my IP" they are HTTPS.

So you could implement HTTPS to address this?


Well-known member
My forum is HTTP and this forum is HTTPS.

Are you saying that this forum will properly detect my real IP when using Data Saver because it is using HTTPS?

On my forum (HTTP) XenForo is unable to detect my real IP.


Well-known member
Yes I believe so, as per your quote they say no data savings will occur for "secure/HTTPS" websites. So the visitor's IP will be exposed because they are not going through the Google proxy for HTTPS websites.


XenForo developer
Staff member
We record the IP that connected to the server, not the untrusted and spoofable forwarded IP. Recording the spoofable IP (only) would create a vulnerability and a trivial way to hide where you're actually connecting from.

As such, this is what's expected.


Active member
To expand a little, when using Chrome's data saver system HTTP traffic is proxied through Google's servers which will modify your HTTP request and add a few extra headers:

  • The "Via" header which is set to "1.1 Chrome-Compression-Proxy"
  • The "Forwarded" header, which is set to "for=x.x.x.x" (where x.x.x.x is the real IP address)
The problem that arises is that anyone can modify the headers they send with a HTTP request which means they could evade IP bans etc if XenForo trusted the IP address sent in the "Forwarded" header to be accurate.

That said, when using the proxy I noticed requests were sent from If you perform an rDNS lookup you'll see this:

➜  ~  dig -x

; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> -x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51778
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;    IN    PTR


;; Query time: 27 msec
;; WHEN: Sun May 03 16:52:19 BST 2015
;; MSG SIZE  rcvd: 106
Given that Google doesn't allow random people to create A records, XenForo could look up the hostname of the user's IP address (perhaps as a deferred task if it would take too long to do during the page load), check to make sure the A record of the hostname matches up with the user's IP address (stops users setting up PTR records to hostnames they don't own) before making sure that the hostname is in the form of google-proxy-(.*) At this point, you can assume that Google is trustworthy and that the you know the user's real IP address from the Forwarded header. To save time for other visitors, you can add the IP address to a list of trusted proxies for a set amount of time.