This is certainly the result of WhoaMan sticking things "behind nginx". The real/true Internet IP address of the client has to be passed in to the back end via the
X-Real-IP HTTP header, and/or
X-Forwarded-For.
The situation becomes complicated if PHP is being used on the back end (via FastCGI) or similar, especially under nginx. The software being run (PHP, etc.) has to parse/honour the new headers in software through CGI variables/params. For FastCGI, you need to use the
fastcgi_param REMOTE_ADDR $http_x_real_ip; directive to get it to set $REMOTE_ADDR to the actual Internet client's IP address.
There is also the
ngx_http_realip_module extension (for the back end) which comes in extremely handy. However, configuring this correctly so that end-users can't override things (thus spoofing the IP that shows up on the back end) is important. It's very easy to screw this up. Actually, I just realised there's a website that kind of talks about most of this (not all of it though, particularly the security aspect -- instead refer to the nginx module doc I linked for that):
https://easyengine.io/tutorials/nginx/f ... s-real-ip/
If Apache is being used on the back end, then the admin gets to figure out equivalents there. I believe there's an Apache 2.x module called mod_rpaf that is the Apache equivalent of ngx_http_realip_module.
Again a reminder:
when implementing this, please be sure to test the security aspect. Try doing things from an Internet host like
curl -H "X-Real-IP: 69.69.69.69" http://wiki.nesdev.com/info.php (where info.php is a PHP script containing
<?php phpinfo(); ?> and see what the "client IP" shows up as (if it shows up as 69.69.69.69, then that's bad/people can bypass it. Look into
set_real_ip_from). Same goes for testing
X-Forwarded-For. Check your HTTP access logs too -- make sure the right IP shows up there (if multiple servers on the front end are around, then you might consider extending the access logs to print both the IP of the front end server *and* the
$http_x_real_ip address). Finally, the
real_ip_recursive value (on or off) matters TREMENDOUSLY and is actually hard to get right (the documentation describes it in such a way that makes it difficult to understand) -- you may need to try both values, and try the security tests in both cases. You might be surprised what you see (
X-Forwarded-For is a clusterfuck).
And now folks hopefully understand why we never used reverse proxying on Parodius -- it's a nightmare for web hosting. The negatives of it, IMO, outweigh the positives; it drives the users insane. (Please do not discuss scaling etc. in this thread -- that's a separate sysadmin subject that can be discussed privately some other time).