If you enter your WordPress admin credentials correctly and the page just reloads wp-login.php instead of taking you to the dashboard — no error message, just a loop — the cause is almost never a wrong password or a corrupted WordPress install. On sites proxied through Cloudflare, this is a well-documented conflict between Cloudflare's edge security features and how WordPress and security plugins handle login cookies and challenge pages. Work through the checks below in order, starting with the lowest-risk one.

Symptoms

  • Entering the correct username and password redirects back to the login form instead of the dashboard.
  • No visible error message, or a generic "cookies are blocked" notice appears.
  • The loop happens consistently for admin/wp-login.php specifically, while the rest of the site loads fine.
  • It may have started right after enabling a Cloudflare security feature (Bot Fight Mode, Turnstile, Super Bot Fight Mode) or changing the SSL/TLS encryption mode.
  • Logging in works from some networks or devices but not others.

Likely causes, in order of how often they actually happen

  1. Cloudflare's security level is aggressively challenging the login request. Cloudflare's Security Level and bot-management settings can intercept requests to wp-login.php before they reach WordPress, especially from IP addresses or user-agents it scores as suspicious. This is the single most common cause and the easiest to rule out.
  2. A Wordfence + Cloudflare Turnstile conflict. Wordfence's two-factor authentication / login-security flow and Cloudflare's Turnstile challenge (Cloudflare's CAPTCHA replacement) can both try to control the same login form submission. When both are active, Wordfence has been documented to occasionally reject or fail to complete the login handshake after Turnstile's challenge passes, sending the browser back to the login form in a loop.
  3. Bot Fight Mode is challenging your own login attempts. Bot Fight Mode is tuned to catch automated traffic, but it doesn't understand WordPress's login flow specifically. It has a known pattern of intermittently issuing challenge pages to legitimate admins hitting wp-login.php repeatedly (which happens naturally if you're already stuck in a loop), making the problem worse rather than causing it initially.
  4. SSL/TLS mode mismatch between Cloudflare and your origin server. If Cloudflare is set to "Flexible" but your server actually serves HTTPS (or vice versa), WordPress can end up generating login cookies against the wrong scheme, so the auth cookie WordPress sets doesn't validate correctly on the next request. This is less common than the first two but does happen after a Cloudflare setting change or a migration.

Saddened ethnic male in casual outfit holding head thinking about bad news about project while working remotely alone on laptop in park

Fix it: lowest-risk steps first

Step 1 — Temporarily lower Cloudflare's Security Level and test

This is the lowest-risk, fastest diagnostic step and doesn't touch WordPress at all.

  1. Log in to the Cloudflare dashboard for the domain.
  2. Go to Security → Settings (on older dashboard layouts, this is under the Security tab's overview).
  3. Find Security Level and temporarily set it to Essentially Off or Low.
  4. Wait about 30 seconds for the change to propagate, then try logging in to wp-admin again in a fresh incognito/private window (to rule out a stuck cookie).

If login now works, you've confirmed Cloudflare's edge rules are the cause. Don't leave Security Level permanently lowered — instead, add a WAF custom rule (Security → WAF → Custom rules) that skips challenges specifically for requests to /wp-login.php and /wp-admin/* from your own known IP address, then restore the site-wide Security Level to its previous setting.

Step 2 — Check for the Wordfence + Turnstile conflict specifically

If Step 1 didn't fix it, or you're using Wordfence's login security (2FA or the login CAPTCHA feature) alongside Cloudflare Turnstile:

  1. In Cloudflare, go to Security → Bots (or Turnstile under the main dashboard menu if you have a standalone widget configured) and check whether a Turnstile widget or managed challenge is active for the login path.
  2. In WordPress, go to Wordfence → Login Security and temporarily disable the CAPTCHA/challenge option there (leave two-factor authentication itself on if you rely on it).
  3. Test login again. If it succeeds with Wordfence's own challenge disabled, the two systems were double-challenging the same request. Keep only one in place — either Cloudflare's Turnstile rule for the login page, or Wordfence's built-in login protection, not both simultaneously.

Step 3 — Rule out Bot Fight Mode interference

  1. In Cloudflare, go to Security → Bots.
  2. If Bot Fight Mode (or Super Bot Fight Mode on paid plans) is enabled, temporarily turn it off.
  3. Retry the login in a private browser window.

If this resolves it, re-enable Bot Fight Mode afterward but add an IP-based allow rule for your own admin IP address under Security → WAF → Tools → IP Access Rules, set to Bypass, so future logins aren't re-challenged.

Step 4 — Check for an SSL/TLS mode mismatch

This is the last thing to check because it requires touching a setting that affects the entire site, not just login.

  1. In Cloudflare, go to SSL/TLS → Overview and note the current mode.
  2. Confirm your origin server actually has a valid SSL certificate installed and serves the site over HTTPS directly (test by temporarily viewing the site through your server's IP address or asking your host).
  3. If your server does serve valid HTTPS, set Cloudflare's mode to Full (strict). If your server does NOT have a valid certificate at the origin, Full (strict) will break the site — in that case use Full (non-strict) instead, or fix the origin certificate first.
  4. Clear your browser cookies for the domain and retry login.

A mismatched mode (commonly "Flexible" on a site that actually has HTTPS at the origin) causes WordPress to see inconsistent request schemes between page loads, which can prevent the auth cookie from validating correctly.

Verify the fix

  1. Log in to wp-admin successfully from a fresh private browser window, with no leftover cookies.
  2. Log out and log back in a second time to confirm it wasn't a one-off.
  3. Test from a different network (e.g., mobile data instead of home Wi-Fi) to confirm it isn't IP-specific.
  4. Re-check that any settings you loosened (Security Level, Bot Fight Mode) are restored to their normal protective state, with a specific allow rule in place for the admin login path instead.

If you need to roll back

If none of the above resolves the loop, revert every Cloudflare setting you changed back to its original value (Security Level, Bot Fight Mode, SSL/TLS mode) — write down the before-value before each step so this is a straight undo. If the site becomes unreachable after an SSL/TLS mode change specifically, switching the mode back to Flexible immediately restores basic access while you investigate the origin certificate separately. If you're fully locked out of wp-admin with no other way in, you can always disable Cloudflare's proxy entirely (grey-cloud the DNS record) as a last resort — this routes traffic directly to your server, bypassing every Cloudflare-side challenge while you fix the underlying conflict.

Related fixes

FAQ

Is it safe to just turn off Cloudflare's proxy permanently to avoid this?

You can, but you'd lose Cloudflare's CDN caching, DDoS protection, and firewall for the whole site, not just the login page. A targeted fix — an IP allow rule or a WAF rule scoped to /wp-login.php — solves the login loop without giving up Cloudflare's protection everywhere else.

Why does this only happen to me and not other admins on the same site?

Cloudflare's bot scoring and challenge decisions are partly based on your specific IP address, browser fingerprint, and recent request pattern. A different admin on a different network or browser may simply not trigger the same challenge, even with identical Cloudflare settings.

Could a caching plugin also be involved?

It's possible but much less common than the Cloudflare-side causes above. If Steps 1–4 don't resolve it, temporarily add your site's domain to your caching plugin's exclusion list for /wp-login.php and /wp-admin/* (most caching plugins exclude these by default, but a custom configuration can override that) before assuming there's a deeper WordPress-level issue.

Do I need a paid Cloudflare plan to fix this?

No. Security Level, Bot Fight Mode, IP Access Rules, and basic WAF custom rules are all available on Cloudflare's free plan. Turnstile itself is also free to configure. Super Bot Fight Mode's more granular controls are a paid-plan feature, but the free-plan equivalents are enough to resolve this specific conflict.