Hi @ibiza69,
Thanks for reporting this — I can help you narrow down what’s going on. Based on the behavior you’re describing (lockouts not triggering despite correct threshold settings), there are a few common causes to check:
1. Admin IP Auto-Whitelist (most likely cause)
Solid Security has a setting called “Automatically Temporarily Authorize IPs” under Settings → Global Settings → Authorized IPs. This is enabled by default, and it means that whenever an admin user accesses the site, their IP is automatically whitelisted for 24 hours. So if you’re testing lockouts while logged in as an admin (or from the same IP you recently used to log in as admin), the lockout will never trigger — even though the failed attempts are being counted internally.
To test properly, you’d need to either:
- Temporarily disable “Automatically Temporarily Authorize IPs” in Global Settings, or
- Test from a completely different IP address (e.g., a VPN, mobile data, or a different network) that has never been used to log into the admin area.
2. IP Detection Configuration
Solid Security requires IP detection to be properly configured for lockouts to work. If it’s set to “Unconfigured,” lockout enforcement is disabled entirely. You can check this under Settings → Global Settings → IP Detection → Proxy Detection.
If it currently says “Unconfigured”:
- If your site is not behind a proxy/CDN (like Cloudflare), set it to “Disabled” (which uses
REMOTE_ADDR directly).
- If your site is behind a proxy/CDN, set it to “Manual” and select the correct header (e.g.,
HTTP_CF_CONNECTING_IP for Cloudflare).
- If you’re on Solid Security Basic (free), make sure Security Check Pro is enabled under Settings → Features → Utilities — this unlocks the recommended “Security Check Scan” option for IP detection.
More details here: https://solidwp.com/documentation/security/how-it-works/frequently-asked-questions/#h_01hsgm6nsk5gnymxe1a6ad65ez
3. Authorized IPs List
Also check Settings → Global Settings → Authorized IPs to make sure your testing IP hasn’t been manually added there. Any IP on that list is permanently exempt from lockouts.
Could you let me know:
- How exactly are you testing — are you logging out of the admin first, or opening an incognito/private window and trying from there?
- What does your Proxy Detection setting say under Global Settings → IP Detection?
These two details will help us pinpoint the issue quickly.
Best regards,
Paweł
Thank you @solidwppawel !
I tested with “Incognito Window“, maybe this doesn’t work?
We don’t use a proxy (not behind a proxy/CDN), and at Proxy config we have: “Recommended”, so you tell me to change it to: “inactive” or “unconfigured”?
At: Security Check Pro is: “enabled“
And at Settings → Global Settings → Authorized IPs: I don’t have my IP there either 🙂
Hope this information helps, thanks a lot for your kind help.
Thanks for the details — those help a lot!
Two quick clarifications first:
Proxy Detection: “Recommended” — this is perfect, don’t change it. “Recommended” means Security Check Pro contacted our servers and auto-detected the correct IP detection method for your server. Since Security Check Pro is enabled and you’re not behind a proxy/CDN, this is exactly the right setting.
Incognito window testing — this is the part that’s tripping you up. An incognito/private window only clears cookies and session data — it does not change your IP address. And the admin auto-whitelist in Solid Security is tied to your IP, not your browser session.
Here’s what’s happening: when you successfully log into the site as an admin, Solid Security automatically whitelists your IP for 24 hours (this is the “Automatically Temporarily Authorize IPs” setting under Security → Settings → Global Settings → Authorized IPs, enabled by default). So when you then try your 40 failed attempts from the same IP — even in incognito — the lockout logic sees your IP is on the temp-whitelist and skips the lockout entirely. Failed attempts are still counted internally, but enforcement is bypassed.
To test lockouts properly, do one of these:
- Temporarily disable the auto-authorize option. Go to Security → Settings → Global Settings → Authorized IPs and uncheck “Automatically Temporarily Authorize IPs”. Save, then try your failed-login test. Re-enable it afterwards if you want it back on.
- Test from a different IP. Use mobile data (turn off Wi-Fi on your phone), a VPN, or another network that has never been used to log into the admin. From that IP, do 5 failed login attempts — you should get locked out on the 6th.
Either approach will give you an accurate test. Option 2 is closer to what a real attacker would experience, so if you can, that’s the more realistic check.
Give that a try and let me know how it goes.
Best regards,
Paweł
