Together they cover volume attacks, regional bot farms, and known threats in one pass. Configured in the wrong order, they also cover you – the admin trying to log in from a hotel Wi-Fi in another country during rate-limit testing.<\/p>\n\n\n\n
BruteFort runs all three layers from one settings panel – the rest of this guide shows how to configure them together without locking yourself out.<\/p>\n\n\n\n
Step 1: Whitelist Your Own Access First<\/h2>\n\n\n\n
Before touching rate limiting or geo-blocking, add your own IP address (and anyone else who administers the site) to the IP whitelist. Whitelisted IPs bypass rate-limit lockouts and geo-blocking rules entirely – exactly what you want while you’re actively configuring the other two layers.<\/p>\n\n\n\n
If your IP changes regularly (many home and mobile connections do), whitelist the widest range your ISP is likely to assign. Or plan to update the whitelist entry when your IP rotates. A dynamic IP is the single most common cause of an admin accidentally locking themselves out days after setup was finished.<\/p>\n\n\n\n Set your failed-attempt threshold and lockout duration next, while your own access is already protected by the whitelist. A starting point that works for most sites: 5 failed attempts, 15-minute lockout.<\/p>\n\n\n\n Tighter than that, and a legitimate user who mistypes a password twice is at real risk of locking themselves out. Looser than that, and you’re not meaningfully slowing a brute-force script.<\/p>\n\n\n\n Test it from a device on your own network before moving on. Deliberately fail a login 5 times and confirm you see the lockout message, then confirm it clears after the duration you set.<\/p>\n\n\n\n Geo-blocking is the layer most likely to lock out a legitimate person. It blocks by default rather than by behavior – it doesn’t care whether the login attempt looks like an attack, only where it came from.<\/p>\n\n\n\n Before enabling it, list every country anyone with legitimate admin access might log in from. That includes contractors, agencies, and your own travel.<\/p>\n\n\n\n Allow-list those countries rather than trying to block-list every country you’ve never heard from. It’s a shorter, safer list to maintain, and it fails safe: a new country you forgot to add gets blocked – annoying, but recoverable. A country you forgot to block staying open is a real gap.<\/p>\n\n\n\n Three specific situations cause almost every self-lockout with this combination:<\/p>\n\n\n\n If you’re locked out of wp-admin by your own rules, you still have file access via FTP or your host’s file manager – and that’s the way back in every time. Rename BruteFort’s plugin folder inside WordPress auto-deactivates any plugin whose folder it can’t find. That clears rate-limit, geo-blocking, and custom-login-URL restrictions immediately. Log back in through the default This is also why BruteFort deliberately doesn’t require server-level configuration – no Whitelist your own IP first, set and test rate limiting second, then add geo-blocking last. This order protects your own access before the layers most likely to lock out a legitimate admin get switched on.<\/p>\n\n\n\n They don’t conflict technically – a whitelisted IP always overrides both rate limiting and geo-blocking. But they can combine to lock out a legitimate user if the whitelist isn’t kept current, or if the geo allow-list doesn’t cover everywhere admins actually log in from.<\/p>\n\n\n\n Access your site via FTP or your host’s file manager and rename BruteFort’s plugin folder inside Rate limiting alone stops the most common attack (automated password guessing) and is the minimum worth running. Geo-blocking and IP rules add real protection against attacks rate limiting misses, but they also add configuration risk. Add them once rate limiting is working and tested, not all three at once.<\/p>\n\n\n\n![\"BruteFort](\"https:\/\/brutefort.com\/blog\/wp-content\/uploads\/2026\/07\/brutefort-ip-settings.webp\")
<\/figure>\n\n\n\nStep 2: Set Rate Limiting Before Geo-Blocking<\/h2>\n\n\n\n
![\"BruteFort](\"https:\/\/brutefort.com\/blog\/wp-content\/uploads\/2026\/07\/brutefort-rate-limiting-settings.webp\")
<\/figure>\n\n\n\nStep 3: Add Geo-Blocking Last, and Check Your Own Travel Patterns First<\/h2>\n\n\n\n
![\"BruteFort](\"https:\/\/brutefort.com\/blog\/wp-content\/uploads\/2026\/07\/brutefort-geo-blocking.webp\")
<\/figure>\n\n\n\nThe Self-Lockout Scenarios to Test For<\/h2>\n\n\n\n
\n
How to Recover If You Lock Yourself Out<\/h2>\n\n\n\n
\/wp-content\/plugins\/<\/code> to something like brutefort-disabled<\/code>.<\/p>\n\n\n\n\/wp-login.php<\/code>, rename the folder back, and reconfigure with a wider whitelist or allow-list before re-enabling.<\/p>\n\n\n\n.htaccess<\/code> rules to hunt down. A plugin-level lockout is always recoverable this way, in minutes, without support access to your host.<\/p>\n\n\n\nFrequently Asked Questions About Layered Login Protection<\/h2>\n\n\n\n
What order should I configure rate limiting, geo-blocking, and IP rules in?<\/h3>\n\n\n\n
Can these three features conflict with each other?<\/h3>\n\n\n\n
I’m locked out of my own WordPress site. What do I do?<\/h3>\n\n\n\n
\/wp-content\/plugins\/<\/code>. WordPress will automatically deactivate it, clearing the lockout. Log in, rename the folder back, and reconfigure with a wider whitelist or allow-list.<\/p>\n\n\n\nDo I need all three layers, or is one enough?<\/h3>\n\n\n\n
Related Reading<\/h2>\n\n\n\n
\n