Fixing the 127.0.0.1 Redirect Loop in AIOS Brute Force Protection
Content
Understanding the 127.0.0.1 Redirect Problem
Many users of the All-In-One Security (AIOS) plugin encounter a frustrating issue: being redirected to http://127.0.0.1 (localhost) when trying to access their WordPress login page. This behavior is almost always tied to the plugin's "Cookie Based Brute Force Prevention" feature, designed to block unauthorized access to your login form.
This redirection occurs because the security mechanism is active, but your browser either does not have the required special cookie, or the cookie has expired or been deleted. The feature works by only allowing access to wp-admin or your renamed login page if a specific cookie is present. This cookie is set by visiting a special URL containing your secret word (e.g., yoursite.com?your_secret_word=1). If the cookie is missing or invalid, the plugin redirects the request to 127.0.0.1 to block the login attempt.
Why Does This Happen?
Based on community reports, the most common causes for this redirect loop are:
- Forgotten Secret Word: The admin enables the feature but forgets the custom secret word they set.
- Browser Cookie Deletion: Clearing the browser's cache and cookies also removes the special AIOS cookie, locking the admin out.
- Plugin or Theme Conflict: Certain configurations, especially with caching plugins, can interfere with the cookie being set or recognized properly.
- Plugin Updates: In some instances, updates to the AIOS plugin have introduced temporary bugs affecting how the cookie validation works.
- Incorrect URL Access: Not using the exact correct format for the secret word URL (
?secret_word=1) can fail to set the cookie.
How to Regain Access to Your WordPress Admin
If you are locked out and continuously redirected to 127.0.0.1, follow these steps to resolve the issue.
Solution 1: Use the Secret Word URL (If You Remember It)
The intended way to access your site is by using the secret word. Simply go to your website's homepage URL appended with your secret word. For example:
https://yourwebsite.com/?my_secret_word=1
Visiting this URL should set the necessary cookie in your browser. You can then navigate to /wp-admin or your renamed login page normally. Remember, this cookie typically expires after 24 hours, so you will need to repeat this process daily.
Solution 2: Disable the Feature via wp-config.php
If you cannot remember your secret word, this is the most reliable method. You need to access your website's files via FTP or your hosting provider's file manager.
- Locate your WordPress installation's root directory.
- Find and edit the
wp-config.phpfile. - Just before the line that says
/* That's all, stop editing! Happy publishing. */, add the following line of code:define('AIOS_DISABLE_COOKIE_BRUTE_FORCE_PREVENTION', true); - Save the file and upload it back to the server if necessary.
This constant will completely disable the cookie-based brute force protection, allowing you to log in normally. Once logged in, you can go to WP Security > Brute Force > Cookie Based Brute Force Prevention to review your settings or disable the feature. Remember to remove the line from wp-config.php afterward if you plan to re-enable the protection.
Solution 3: Modify the Plugin's Settings File
For advanced users, another method is to directly edit the AIOS settings file.
- Connect to your site via FTP/File Manager.
- Navigate to
/wp-content/uploads/aios/firewall-rules/. - Locate and edit the
settings.phpfile. - Find the line:
"aios_enable_brute_force_attack_prevention":"1" - Change the
"1"to""(an empty string) to disable the feature. - Save and upload the file.
Note: The structure of this file may change with plugin updates, so this solution may not always work.
Solution 4: Check for Conflicting Settings
If you are not using the cookie-based feature but are still being redirected to 127.0.0.1, other AIOS settings might be the cause. The "Internet bots" firewall rule can sometimes trigger this, especially on sites behind a load balancer or WAF. To check:
- Once you regain access (using Solution 2), go to WP Security > Firewall > Internet bots.
- Temporarily disable the setting for Ban POST requests that have a blank user-agent and referer.
- Save the settings and see if the issue resolves.
Preventing Future Lockouts
- Bookmark the Secret URL: Always save the complete secret word URL (e.g.,
yoursite.com?secret=1) in your browser's bookmarks. - Use with Caching Plugins: Be aware that caching plugins can sometimes serve a cached version of the redirect. Ensure your caching plugin is configured to bypass the cache for the admin area and login pages.
- Consider Alternative Protection: If the cookie method proves too problematic for your setup, consider using other AIOS features like "Rename Login Page" or "Login Whitelist" instead of, or in combination with, the cookie-based protection.
This issue is a well-documented challenge within the user community. The 'All-In-One Security (AIOS) – Security and Firewall' team has addressed it in past updates and continues to work on improvements. If problems persist, checking the plugin's changelog for recent fixes may provide further insight.
Related Support Threads Support
-
Cookie based brute force login not workinghttps://wordpress.org/support/topic/cookie-based-brute-force-login-not-working/
-
Redirect to http://127.0.0.1/https://wordpress.org/support/topic/redirect-to-http-127-0-0-1/
-
Brute forcehttps://wordpress.org/support/topic/brute-force-15/
-
I have change wp-admin URL but i still receive brute force attackshttps://wordpress.org/support/topic/i-have-change-wp-admin-url-but-i-still-receive-brute-force-attacks/
-
Brute force cookie prevention not workinghttps://wordpress.org/support/topic/brute-force-cookie-prevention-not-working/
-
brute force attackshttps://wordpress.org/support/topic/brute-force-attacks-15/
-
Terrible Cookie Based Brute Force Login Attack Problemhttps://wordpress.org/support/topic/terrible-cookie-based-brute-force-login-attack-problem/
-
Possible bughttps://wordpress.org/support/topic/possible-bug-43/
-
Redirect to 127.0.0.1 when most related settings are NOT enabled.https://wordpress.org/support/topic/redirect-to-127-0-0-1-when-most-related-settings-are-not-enabled/
-
Cookie-based Brute Force Protection not working properlyhttps://wordpress.org/support/topic/cookie-based-brute-force-protection-not-working-properly/
-
Cookie-based brute force not working properlyhttps://wordpress.org/support/topic/cookie-based-brute-force-not-working-properly/
-
Brute force incorrect redirectshttps://wordpress.org/support/topic/brute-force-incorrect-redirects/
-
Brute Force still having hitshttps://wordpress.org/support/topic/brute-force-still-having-hits/
-
Always redirect when try to reach login pagehttps://wordpress.org/support/topic/always-redirect-when-try-to-reach-login-page/
-
Cookie-based brute force stops working after 24 hourshttps://wordpress.org/support/topic/cookie-based-brute-force-stops-working-after-24-hours/
-
Brute Force – Login Whitelisthttps://wordpress.org/support/topic/brute-force-login-whitelist-2/
-
Bruteforce attackshttps://wordpress.org/support/topic/bruteforce-attacks/
-
Brute Force configuration are not taken into considerationhttps://wordpress.org/support/topic/brute-force-configuration-are-not-taken-into-consideration/
-
Cookie Based Brute Force Protectionhttps://wordpress.org/support/topic/cookie-based-brute-force-protection-2/
-
Can’t login after enabling brute force protectionhttps://wordpress.org/support/topic/cant-login-after-enabling-brute-force-protection/
-
Cookie slug leeds to 127.0.0.1 seems not accepted since last update?!https://wordpress.org/support/topic/slug-leeds-to-127-0-0-1-seemsnot-accepted-since-last-update/
-
endless brute force attackhttps://wordpress.org/support/topic/endless-brute-force-attack/
-
Brute force attack prevention wrong redirectionhttps://wordpress.org/support/topic/brute-force-attack-prevention-wrong-redirection/
-
AIOS dashboard redirects to 127.0.0.1 (brute force prevention issue?)https://wordpress.org/support/topic/aios-dashboard-redirects-to-127-0-0-1-brute-force-prevention-issue/
-
problem after activating cookie based brute force protectionhttps://wordpress.org/support/topic/problem-after-activating-cookie-based-brute-force-protection/