If you keep getting thrown back to a Cloudflare "Checking your browser" or "Verify you are human" screen every time you try to reach /wp-login.php or /wp-admin/ — and it never actually lets you through, or it lets you through and then asks again a minute later — this is Cloudflare's Managed Challenge re-triggering on your own login traffic. It's almost always caused by the domain's Security Level being set too high combined with something in your own connection (a shared IP, a VPN, a hosting-provider IP range, or repeated failed login attempts) that keeps scoring as suspicious. The fix is either to lower the challenge sensitivity for the site generally, or — better — to create a narrow rule that stops challenging requests to the login URLs specifically.

Symptoms

  • Visiting wp-login.php or wp-admin shows a Cloudflare interstitial page ("Checking if the site connection is secure" or "Verify you are human") instead of the WordPress login form.
  • Completing the challenge briefly lets you in, then the same challenge reappears on the next page load or after submitting the login form.
  • The loop happens consistently for you (the site owner or an editor) even though regular visitors to the rest of the site don't report it.
  • It got worse recently after you changed Cloudflare's Security Level, added a firewall rule, or after Cloudflare rolled out a security update on their end.

Likely causes, in order of how often they actually happen

  1. Security Level is set to "High" or "I'm Under Attack" in Cloudflare, which challenges a much larger share of traffic — including you — especially if you're on a VPN, mobile carrier NAT, or shared office IP that has a lower reputation score.
  2. A Cloudflare WAF managed rule or rate-limiting rule is scoring wp-login.php traffic as bot-like, because login pages are a common brute-force target and Cloudflare's managed rulesets specifically watch them more closely than normal pages.
  3. Repeated failed logins from your own testing (wrong password attempts, a saved bad password in a browser autofill, or a security plugin's own lockout) are adding to your IP's threat score, making Cloudflare challenge you more aggressively on subsequent attempts.
  4. A browser extension, corporate proxy, or shared VPN exit node is altering your request headers or IP reputation in a way that looks automated to Cloudflare's challenge logic, independent of anything on your WordPress site.

Fix it: lowest-risk steps first

Step 1 — Lower the Security Level for the domain (fastest, temporary fix)

In the Cloudflare dashboard, go to Security → Settings and find Security Level. Change it from High (or whatever it's currently set to) down to Medium or Essentially Off for a few minutes and try loading wp-login.php again in a private/incognito window.

  • If the loop stops, you've confirmed Security Level is the trigger. This is a fine temporary fix, but leaving the whole site at a lower security level long-term reduces protection against real bot traffic, so treat this as diagnostic — move on to Step 2 to fix it properly rather than leaving Security Level low permanently.

Step 2 — Create a WAF custom rule that skips the challenge for the login path

This targets only the pages that need it, instead of lowering security sitewide. In the Cloudflare dashboard:

  1. Go to Security → WAF → Custom rules and click Create rule.
  2. Set the rule to match when URI Path contains /wp-login.php or URI Path contains /wp-admin/.
  3. For the action, choose Skip and select the specific security features to skip — typically "Managed Challenge" (and, if present, "Super Bot Fight Mode" or the relevant bot-management check). Do not choose "Skip all remaining rules," since that also disables rate limiting and other WAF protections you likely still want on this path.
  4. Deploy the rule and reset the Security Level back to your normal setting (High or whatever you had before Step 1) — the new rule is now doing the targeted work instead.
  5. Test again in a private window: the login page should load without a challenge, while other parts of the site (and other visitors' login attempts) still go through normal security checks.

Step 3 — Scope the bypass to your own IP address (recommended if you have a static IP)

Fully exempting /wp-admin/ from challenges — even from Step 2 — means anyone who finds your login URL also skips the challenge, which is a meaningful reduction in brute-force protection. If your office, home, or VPN connection uses a static IP (or a small stable range), tighten the rule:

  1. Edit the custom rule from Step 2 and change the condition to an AND: URI Path contains /wp-login.php or /wp-admin/, AND IP Source Address is in your specific IP (or IP list).
  2. If you don't have a static IP, an alternative is to keep the path-based rule from Step 2 but pair it with a stricter rate limit on /wp-login.php (Security → WAF → Rate limiting rules) so brute-force attempts still get blocked even though the challenge itself is skipped.
  3. Save and confirm the login page loads normally from your own connection.

Verify the fix

  1. Load /wp-login.php in a private/incognito window from your own network and confirm no Cloudflare interstitial appears.
  2. Log in normally and confirm you're not asked to re-verify on the next page load inside wp-admin.
  3. Check Security → Events in Cloudflare a day later to confirm login-path requests from your IP are no longer being challenged, while unrelated traffic elsewhere on the site still shows normal security activity.

If you need to roll back

If the custom rule causes unexpected access issues (for example, a real attacker probing the login page no longer gets challenged at all), delete or disable the rule under Security → WAF → Custom rules and restore your original Security Level under Security → Settings. This immediately returns the site to its prior protection level while you reconsider the IP-scoped version in Step 3.

Related fixes

FAQ

Will lowering the Security Level make my whole site less safe?

Yes, if left there permanently — it's meant as a quick diagnostic step in Step 1, not the actual fix. The WAF custom rule in Step 2 is the intended long-term solution because it only relaxes checking on the login path, leaving the rest of the site's security untouched.

Why does this only happen to me and not other visitors?

Because Managed Challenge decisions are based partly on your specific connection's reputation signals (IP history, VPN/proxy use, request patterns), not a fixed rule that treats all visitors the same. Two people visiting the same login page can get different outcomes.

Is it safe to fully whitelist wp-admin from all security checks?

Not recommended. /wp-admin/ and /wp-login.php are among the most commonly attacked WordPress paths, so removing all Cloudflare protection there — rather than just the challenge, as in Step 2 — leaves you relying entirely on WordPress's own login protections (like a security plugin's login limiter). If you go this route, pair it with strong WordPress-level login protection and, ideally, the IP restriction from Step 3.