Fixing this requires to have more information about the environment where you encountered this issue as the current code works for every other website. You are part of a small group of people that have reported this issue in the past and it was always product of a misconfiguration of the server where the website is/was being hosted or with an additional extension that was overriding the value of the global server variable REMOTE_ADDR.
People with the reverse proxy option enabled were also experiencing this issue as their websites were not behind a proxy nor a firewall so the IP address was being reverted to one of the loopbacks.
I will mark this as resolved (per the explanation above) we can reopen the ticket once you provide the information that I need to reproduce the issue in my own server as that is the only way I can investigate and possibly fix the problem.
The REMOTE_ADDR server variable will work when they’re NOT using a reverse proxy. This is the majority of all WordPress users. But 100% relying on this server variable is not good, because in cases where they do use a reverse proxy, the value of this variable becomes unreliable.
Why not check for the HTTP_X_FORWARDED_FOR server variable FIRST?
If it’s there, you use that IP. If it’s not there, use the REMOTE_ADDR server variable.
This makes your user IP retrieving mechanism more reliable in cases where they use a reverse proxy like cloudflare.
Yes, that is an option too, to check X-Forwarded-For first; the thing is, every header prefixed with “HTTP” can be easily spoofed, so if I change the code to accept X-Forwarded-For first it will allow malicious users to send arbitrary IP addresses to hide the real origin of the request.
curl -H "X-Forwarded-For: 31.13.74.1" "http://example.com/"
The previous command will force the plugin to log that IP address (which at the time is associated to Facebook’s network) instead of his/her real IP; during an audit you would start asking why someone from Facebook would be attacking your website.
The custom headers used by CloudFlare and Sucuri and many other firewalls can be trusted only when the owner of the site explicitly enables the reverse proxy option because if the website is indeed behind a firewall then the IP address is surely in that header, otherwise it is unsafe; this option is opt-in and not opt-out to protect the majority of users.
