That’s correct: you should get a 404 HTTP code. If the bot protection is off and the Login protection set to “Always ON”, you should get a 401 code.
I’ll check in the next version if we can whitelist Site Health again. We already had to do that for its PHP session test.
Thread Starter
dimal
(@dimalifragis)
I never set it to Always ON, i use When under attack, and Enable bot protection On.
I leave When under attack ON and Disabled bot protection. That works for loopback.
When botn ON, it fails.
What shall i use?
Unless you have a script that needs to connect to the login page (wp-login.php), you can keep your current configuration. Site health fails, but that’s just its test that fails, your blog will still work as usual. We had the same problem with PHP sessions: Site health added a critical warning about the session that blocked the loopback test, but it was wrong. We had to add some code to get rid of the critical message so that users weren’t scared.
Thread Starter
dimal
(@dimalifragis)
Thanks, crystal clear.
Due to several issues with plugins and Gutenberg, we have downgraded to 5.5.3, so all good as before.
