Support

I believe that you have set up an administrator secret URL parameter but that person is not using it, or using it improperly.

As for your troubleshooting:

• What is logged is configurable. If you have added Admin Query String in "Do not log these reasons" this block reason will not be logged.
• If you have set Log blocked requests to No nothing will be logged.
• Remember that Keep A Debug Log File will only write to the log file what is being logged. The aforementioned two cases where this block or anything at all is not logged also applied to the log file.
• The Site IP Allow List only is a whitelist. It only applies when "Allow administrator access only to IPs in Exclusive Allow IP List" is enabled. What you are looking for is "Never block these IPs" in the Configure WAF page.
• IP addresses tend to change. I have seen very few ISPs which will keep your IP address static without asking for a hefty monthly payment.

Ultimately, I believe the issue can be resolved by simply letting that person know that instead of visiting https://www.example.com/administrator they must visit https://www.example.com/administrator/index.php?your_secret_word.

Are you behind a CDN, e.g. CloudFlare? If so, make a rule that all https://www.example.com/administrator* URLs (note there's intentionally no slash between administrator and the star) are non-eligible for caching – replace www.example.com with your own site's domain, of course. Otherwise, when one person gets blocked – whoever that may be – anyone else accessing that URL will see that block message.

Your claim that Behind Load Balancer made the real visitor IPs available is diametrically incompatible with your assertion that your site is not behind a CDN, load balancer, reverse proxy, or opaque network infrastructure in general. There is a causal relationship between Behind Load Balancer making real IPs available (which were previously unavailable) and being behind opaque network infrastructure. You are wrong about one of your assertions. I cannot tell you which one. From where I am, I see your site resolve to an IP that belongs to IONOS. I don't know what goes on behind it; only your host can answer that.

Your browser has nothing to do with your IP address. But what you were previously describing is an IP block.

Moreover, you claim that Admin Tools blocks you, you have checked that logging is enabled, nothing is excluded from logging, but there is no log for you getting blocked... yet there are log entries for other requests getting blocked. I can tell you upfront that what you are describing is impossible. Logging takes place BEFORE your request is blocked, which takes place BEFORE your IP address is blocked. Assuming you checked that logging blocked requests is enabled and excluding from the log is empty, you can't be blocked by Admin Tools without a corresponding Blocked Requests Log entry. The fact that you see blocked entries from other people means that logging blocked requests is enabled. Check if you are excluding any blocked request type from being logged.

You also claim that Admin Tools blocks you despite the fact your IP is in Never block these IPs. This is also impossible. If the IP your site sees matches a record in that table the security controls are disabled altogether.

Given all that, I conclude that your problem was never with Admin Tools but something else. If you were right about Behind Load Balancer making a difference, your VPS is behind a misconfigured caching reverse proxy. In this case, random Visitor X gets blocked trying to access your backend improperly. Then you visit the same page and your host's caching proxy serves the cached page with the error message. Your changing browsers does absolutely nothing but introduce enough time for that cache to expire.

I am sorry, but this does not actually look like an Admin Tools issue at all.

Now it makes so much more sense!

For what it's worth, last year I had created a containerized site I have misconfigured deliberately. It's there so I can test broken IP forwarding setups. Your configuration ended up accidentally reproducing this broken config on a live server.

The reason I didn't think of it is that in my head, all of my past clients' servers, and my reproduction repository linked above it's always been an "all or nothing" situation. It either happens on the entire site, or not at all. I hadn't seen a site where only /administrator had a misbehaving NginX proxy rule set. Now I know to take that into consideration as well.

Also, for what it's worth, I waved off the browser factor for a reason. The way I read your troubleshooting recount it seemed to me that Firefox was always the last browser you were trying. I assumed that the block is time-constrained and trying all the other browsers wasted enough of your time that the block expired. Therefore, by the time you started using Firefox the block had been lifted, and the browser actually had nothing to do with it. Do tell me if I had a good guess here.

Thank you for pointing us toward the reverse proxy / load balancer angle - that was the key that let us find it. Appreciate your help and patience through this.

I always try to help, even with "impossible" issues. Web servers are deterministic and have no free will. If something's broken, there's a reason. The reason may not be in our software, but I am happy trying to help to the extent humanly possible.

On that note, thank you for being willing to follow my breadcrumbs trying to solve this instead of screaming abuse at me. I don't take it for granted.

I agree on what happened with Firefox.

Have a fantastic day!