Retrieving the correct IP address for a Caddy-WordPress stack

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.

Published
Categorized as Tech

Leave a comment

Your email address will not be published.

5 × 1 =