Geolocation/User IP not updated


I have an issue with the default geolocation in the search bar (please visit the front page of always showing Provo, USA. This is causing confusion for my users who are exclusively in Sweden. I tried to speak to Bluehost who host my site but they don't have any constructive advice on what is causing this. I was wondering if you have any ideas?

Just to clarify, the user's location is perfectly found by pressing the Locate Me button, but any user's IP visiting my site always seems to be from my servers IP address - which also happens to be in Provo, USA I believe.
I also suspect another issue I have with spam registrations could be solved if I would reset so that the actual IP of the user is registered and not my server IP.

Any ideas on how to update so that the user's actual IP address is collected when visiting my site and not my server IP address?
Any other ideas on what may cause this issue or how to resolve it?


  • Adam Czajczyk

    Hello Robin,

    I hope you're fine today and thank you for your question!

    I checked the site and it looks to me like the geo-location scripts are not even fired upon the page load. There's no trace of Google geo-location library being called in the browser console (but it shows up once you use "locate me" button) and browser doesn't ask for permission (which it definitely should do if you have never visited the site before and the site is trying to locate you for the first time).

    That said, I'm not sure how this all (the theme and both plugins) are "tied together" on the site so if you could, please, shed some light on how this is all "interconnected" and configured to work together, that could be of great help.

    Best regards,

  • Robin

    Hi Adam,

    Correct, the location isn't asked for unless the button is clicked. I have a code snippet I can add to automatically press that button though. However it usually asks for permission, so that is a bit surprising.

    I believe the IP-issue is a separate problem however. As any user's IP is shown as my server's IP, the Stop Spammers plugin will allow spammers to register as they seem to have the same IP as the admin (because my IP is also seen as the server's IP).

    I'm not sure where to look for a solution on this sort of issue. And I'm not sure on how things are interconnected either. I can say that I purchased the Listify theme and the above mentioned plugins and this is what I got. Perhaps this documentation can help?
    Or is there something in particular I could try to elaborate for you in case I might know?

    Thanks for doing what you can :slight_smile:

  • Adam Czajczyk

    Hi @robinandaro!

    Initially you were referring mostly to that search bar on the homepage, so that was what I focused on. If a geo-location script is not triggered upon page load, that would explain why it doesn't locate user until the "locate me" button is clicked.

    After looking into these docs that you linked to, I suspect that the fact that the "Provo, USA" is selected by default in such case might be somehow related to WP Job Manger pre-defined regions.

    However, you mentioned "all IPs". Does that mean that even Stop Spammers or for example Defender logs are also showing all users as using the same IP (that points to your servers)? If yes, then I'm thinking of two options here:

    1. One of the plugins that we mentioned in this discussion or a theme might somehow be overriding the IP detected; though that's rather unlikely

    2. There's some server side issue and I'd say that usually would be either some error in server configuration or, more likely, site being behind some sort of proxy/load balancer/CDN/firewall that's somehow "spoofing"/"masking" the IP.

    That wouldn't actually conflict with "manual" geo-location because it's a different thing. The "manual" one (or automatically triggered by that script that triggers "locate me" button) is based on a JS script fired up in user browser and the geo-location is based on a data taken from user browser, then send to the site directly while the server-side detection (e.g. Defender) is using the IP carried over by TCPIP/HTTP.

    That being said, I would like to take another look at your site and "dig deeper" but the support access seems to be inactive now. Would you mind enabling it again for me?

    Let me know once it's active again, please.

    Kind regards,

  • Adam Czajczyk

    Hi Robin

    Thanks for enabling access.

    I checked the site again and did some more "digging" and I actually must say that we're back to your initial idea: that is all - including the search bar "Provo, USA" location - caused by wrong IP detection.

    The "server-side" detection detects user IP as local IP (= server IP) which indeed is geo-located in Provo, Utah, United States.

    The search bar apparently seems to be powered by Google in addition to the pre-defined regions in WP Job Manager so Google takes precedence over that and uses that detected IP if it's not allowed to geo-locate using browser ("locate me" button). So, in a consequence it also geo-locates that IP as Provo, USA.

    Which brings me back to the "CDN/proxy" issue. Such detection means that the site must be behind some sort of "tool" that breaks that IP detection. You seem to be hosting with Bluehost. I'm not sure about the configuration but my bet would be that there's a reverse-proxy.

    In fact, WPMU DEV Dashboard (so working directly "in" your site) detects Apache as webserver but a quick CURL query from outside shows that server responds as nginx webserver. That would confirm the configuration of nginx set as reverse proxy in front of apache. That's quite common setup because it helps achieve better performance and security. The "flow" from user browser is then:

    user browser -> nginx (reverse proxy) -> Apache (your site)

    Now, the nginx gets real IP but then doesn't forward it properly further. That might be on purpose or might be a misconfiguration but anyway - since both nginx and Apache are on the same server, Apache (which serves your site directly) gets IP of a "closer requester" which is nginx in this case. I'm not sure if that clear but I hope it makes some sense to you :slight_smile:

    That said, we can try to diagnose what IPs are actually received by your site. Here's what to do:

    1. download an attached .zip file and extract it to your local drive
    2. access the site via FTP or cPanel "File Manager" tool
    3. upload the "fetch-ips.php" file from inside downloaded archive to the "/wp-content/mu-plugins" folder of your site; if there's no "mu-plugins" folder inside "wp-content" folder, create it
    4. create some empty post or page on your site with "Visibility" set to "Private", or just set it as "Draft" (and I'll take care of it next time I'll access the site)
    5. put this shortcode there


    Once that's done, let me know about the page (so I could find it) and I'll take a look at this to see what it detects. That might give us some additional clue on what's detected and that, in turn, might help us solve that or at least we'd know what to ask host about exactly :slight_smile:

    You can also open the page after adding the shortcode and you should see what IPs has been detected, but still - I'd like to take a look at it as well.

    Best regards,

  • Adam Czajczyk

    Hello Robin

    Thanks for testing that. I checked the page and I"m getting the same result. The HTTP_CLIENT_IP should point to either user real IP or to your server (proxy in this case) IP but that's not a big problem. The HTTP_X_FORWARDED_FOR is an issue, though.

    This is a special HTTP header that should, in fact, carry over IPs that "happen on the way" - in this case it should either contain real user IP or both: your server (proxy) and user IP (site/server would be able to know real one based on this).

    This would mean that the proxy configuration is not properly adding the IP to that header. Meanwhile, I found out about two additional headers that might or might not be set here, where one is an "official replacement" for HTTP_X_FORWARDED_FOR and the other is specific to NGINX so I would like to test them too, if you don't mind.

    To do this, simply download an attached file and just replace the fetch-ips.php on the server (that you previously uploaded) with the new one from an attached zip. Then on the page you should see two additional lines.

    If none of them brings your real IP as well (so either all show server IP or some show nothing and some show server IP) we'll be sure that it's a server side issue related to NGINX configuration.

    Best regards,

  • Adam Czajczyk

    Hello Robin,

    Thanks for checking it and letting me know.

    Yes, in this case I wold definitely consider it a server-side issue. Assuming that I identified the setup (nginx + Apache) correctly, this means that the Apache doesn't get a real IP from nginx.

    This is a matter of nginx configuration then. The HTTP_FORWARDED or HTTPS_X_FORWARDED (ideally, both of them) should contain the real end-user IP which, apparently is not added here. At this point, I think, you would need to start "pushing" a bit on your host so they took a look into that configuration. They would need to make sure that these headers do include end-user real IP.

    There's this handy article on how to set that up, in case they needed it:

    There is also a slight chance that this actually is set up properly in nginx but there's some other aspect of server(s) (as in webservers - nginx/Apache) setup that's "breaking" that but if so, that'd be something we have no way of diagnosing and the host would be the only one to deal with it, I'm afraid.

    Best regards,

  • Robin


    I just wanted to follow up and let you know that Bluehost said I'll have to buy their dedicated server service for 99$ per month in order to edit settings like these.
    I found by not whitelisting my servers IP in plugin Stop Spammers, and introducing code s.t. the "Find me" button is pressed automatically as a user visits the start page, my problems are, at least somewhat, avoided whilst I do not have to spend an extra 99$ per month at this stage.

    So I will mark this ticket as resolved. Thank you so much for your support on this.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.