I use All In One WP Security to secure my Wordpress instance. It’s open source and offers a lot of customization. Though I have entertained the thought of running a static website using WP2Static, I very much dig the existence of comments and searching. Though there have been attempts to merge the aforementioned setup while serving comments from a basic-auth protected wordpress instance, I still have to rely on an external service for searching or make the front document dense with content so that users can CTRL + F to find content. The latter is a half-assed way to implement searching, though many people do it.
The Problem
Now the problem with using the plugin was that when I enabled Brute-Force protection, the only IP that would get blacklisted all the time was an internal IP. It would lock me out. I shamelessly worked around the problem by disabling the plugin, logging in and re-enabling the plugin.
It was a strange issue because Caddy did forward the correct IP address to the backend. I double, triple checked the reverse proxy settings to see if I was missing something. There wasn’t a lot to fix since the reverse proxy settings read as:
reverse_proxy http://wordpress:80
Caddy Docs specify that this directive itself sends all the required headers. It was all the more strange that every other service that I was running was reporting the correct remote IP.
The Solution
While going through the options of the plugin, I found out that it wasn’t Caddy, it wasn’t Apache, it wasn’t even Wordpress. It turns out that the plugin was using the incorrect header to report IP addresses:
HTTP_X_FORWARDED_FOR is what you would want to use instead of the default REMOTE_ADDR.