Fix a WordPress Admin Login Loop Caused by Cloudflare

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. A Cloudflare challenge is intercepting the login request before it reaches WordPress — from a WAF custom rule, a managed rule, Under Attack mode or a bot feature. (Cloudflare's old adjustable Security Level — High, Medium, Low — no longer exists (opens in a new tab); it's fixed at "Always protected.")
2. A Turnstile plugin conflicting with Wordfence 2FA. The Simple Cloudflare Turnstile plugin fixed a bug in version 1.42.0 (opens in a new tab) where its login widget could reset while a two-factor prompt such as Wordfence 2FA was open, making the login fail.
3. Bot Fight Mode is challenging your own repeated login attempts, making an existing loop worse rather than causing it — it doesn't recognize WordPress's login flow specifically.
4. An SSL/TLS mode mismatch between Cloudflare and your origin server is generating login cookies against the wrong scheme, so WordPress's auth cookie doesn't validate on the next request.

Fix it: lowest-risk steps first

Step 1 — Check whether a Cloudflare challenge is involved

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. Open Security → Analytics → Events and look for challenged or blocked requests to /wp-login.php from your IP around the time of the loop.
3. If Under Attack mode is on (Security → Settings), turn it off unless you're actually under a DDoS attack — Cloudflare warns it can affect normal traffic (opens in a new tab).
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 Events shows your login requests being challenged, Cloudflare is the cause. Don't switch protection off for the whole site — instead, create a custom rule on the Security rules page that matches /wp-login.php and /wp-admin/ from your own IP address and uses Skip for the product that issued the challenge (skip options (opens in a new tab)).

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. Check which plugin puts Turnstile on your login form (commonly Simple Cloudflare Turnstile) and update it: the Wordfence 2FA conflict was fixed in version 1.42.0 (opens in a new tab), and support for Wordfence 9 passkeys was added in 1.43.0.
2. In Wordfence → Login Security, check whether Wordfence's own reCAPTCHA (opens in a new tab) is also enabled; running it alongside a Turnstile plugin puts two challenges on the same login form. Keep one of them, and leave two-factor authentication itself on.
3. Test login again in a private window. If it works, keep only one bot check on the login form — either the Turnstile plugin or Wordfence's reCAPTCHA, not both.

Step 3 — Rule out Bot Fight Mode interference

1. In Cloudflare, go to Security → Settings and filter by Bot traffic.
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, you can re-enable Bot Fight Mode, but note it can't be skipped with custom rules (opens in a new tab); the only exception is an IP Access rule that matches first. Create one for your own static admin IP on the Security rules page (Create rule → IP access rules, action Allow). Allow bypasses custom rules, rate limiting and managed rules (opens in a new tab) for that IP, so use it only for an address you control.

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) makes WordPress see inconsistent request schemes between page loads, which can stop the auth cookie from validating and is also a classic cause of redirect loops (opens in a new tab).

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 (Under Attack mode, Bot Fight Mode) are back to their normal protective state, with a specific exception 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 (Under Attack mode, 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 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 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

• Common WordPress Errors and How to Fix Them — For the full guide to telling WordPress errors apart and finding the right fix.
• Cloudflare Challenge Loop on Your WordPress Login — If you see a visible Cloudflare "Checking your browser" or "Verify you are human" screen instead of a silent redirect, that's a different mechanism — see this instead.
• WordPress Login Loop After a Cloudflare Turnstile Update — If the loop happens specifically right after entering your 2FA code, this narrower guide covers that exact conflict.
• Cloudflare Killed Page Rules — Why Your Redirects Broke — If you also have unrelated redirect issues elsewhere on the site.

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. Bot Fight Mode, IP Access rules and basic WAF custom rules are all available on Cloudflare's free plan, and Turnstile is free to use. Super Bot Fight Mode's more granular controls are a paid-plan feature, but the free-plan tools are enough to resolve this specific conflict.