Cloudflare Not Verifying You Are Human? Fix the Loop

When Cloudflare is not verifying you, the "Verifying you are human. This may take a few seconds" page either spins forever or clears and then comes straight back. It is Cloudflare's challenge page: the site asked Cloudflare to check your browser before serving the request, and for most people it passes on its own in a few seconds. A loop means one specific thing is failing: the check cannot run, the pass is not being kept, or the site's rules are aimed at your network. This guide shows how to tell which one you have and what fixes it, whether you are a person stuck on a login screen, a site owner whose visitors are looping, or a developer whose scraper stops at the gate.

What "Verifying you are human" actually means

It means the website is protected by a Cloudflare rule that shows a challenge page instead of serving the content straight away. Cloudflare's documentation describes it as a full-page screen that holds the request while it checks the browser for signs of automation, then lets the original request continue if the check passes.

Site owners choose between three kinds of challenge, according to Cloudflare's challenge-page documentation:

• Non-interactive: JavaScript runs in your browser and decides. You only wait; Cloudflare says this typically takes less than five seconds.
• Managed: Cloudflare picks the challenge based on what it sees. Most visitors pass automatically and see "Successful"; some get a checkbox.
• Interactive: you always have to click. Cloudflare recommends managed challenges instead for most sites.

The checkbox you sometimes see is the same technology as Cloudflare Turnstile. Cloudflare runs challenge pages and the Turnstile widget on the same platform, so the same troubleshooting and the same error codes apply to both.

What happens when you pass

Passing sets a cf_clearance cookie, and that cookie is what lets you browse without being challenged again. Cloudflare's Challenge Passage page gives the default lifetime as 30 minutes, recommends 15 to 45 minutes, and lets the site owner change it. The same page notes that Cloudflare allows a few minutes of clock skew when it validates the cookie, which is why a badly wrong device clock can matter.

Three details from Cloudflare's clearance documentation (updated October 2026) explain most of the confusing behaviour people report:

• The cookie is tied to the visitor and device it was issued to. Copying it to another machine does not carry the pass with it.
• Clearance has levels. Passing a non-interactive check does not clear you for a stricter managed or interactive one later on the same site, so you can pass on one page and be challenged again on the login page.
• It can be revoked early. If the site uses Cloudflare's behavioural session checks in their enforcing mode, a session that starts looking automated can be re-challenged before the cookie expires.

Why Cloudflare is not verifying you: three kinds of loop

Every loop falls into one of three shapes, and the shape tells you where to look. Watch what the page does for one full cycle before changing anything.

What the error code under the checkbox tells you

When the checkbox fails it often shows a short error code, and Cloudflare publishes what those codes mean in its Turnstile error code reference (updated September 2026). None of the top-ranking guides for this problem mention them, but they are the fastest way to skip the guesswork:

Why it keeps looping

A loop means the check keeps failing or the clearance cookie is not being kept. Cloudflare lists the causes in its challenge troubleshooting guide: unstable network connections, browser settings or extensions that block the challenge scripts, unsupported browsers, JavaScript turned off, and genuine detection of bot-like signals.

Two causes come up in almost every forum thread about this screen. The first is cookies: if your browser blocks or clears cookies for the site, cf_clearance never sticks and every page load starts the check again. The second is network reputation: VPNs, shared proxies and some corporate networks carry traffic from many users, and the check is stricter for addresses that have recently sent automated traffic. A VPN that rotates its exit address mid-session also throws away the pass, because the visitor that earned it no longer looks the same.

Browser-specific loops are common too, and the cause is often one setting rather than the browser itself. Three public threads show the pattern (each is one person's report, not a confirmed bug):

• In a Brave community thread from January 2025, the checkbox spun and reset in Brave while the same site passed in Firefox and Chrome. A later reply found that disabling a service-worker-blocking extension fixed it for them.
• In a BleepingComputer forum thread from May 2026, a Firefox 150 user on Windows 10 looped on the checkbox but passed in Chrome's incognito mode; they reported it worked after turning off Firefox's extension and feature recommendation settings.
• In a Level1Techs thread from March 2026, users reported Firefox and Waterfox with hardened privacy settings failing the check far more often, and one user routing all traffic through a rented server being challenged constantly.

The common thread: anything that changes what the browser reports about itself, blocks part of the challenge script, or makes your network look like a data centre can turn a five-second check into an endless one.

How to fix it as a visitor

Work through Cloudflare's own checklist in order, testing the page after each step, and stop as soon as it passes:

1. Update your browser. Turnstile, which runs these challenges, does not support Internet Explorer, and it runs a compatibility check at debug.challenges.cloudflare.com.
2. Disable extensions, especially ad blockers, script blockers and anything that blocks service workers, then reload.
3. Make sure JavaScript and cookies are allowed for the site.
4. Try a private window to rule out stale cookies and cached data.
5. Check your device clock is set automatically. A clock that is far off breaks the timing checks behind codes 200100 and 110600.
6. Make sure challenges.cloudflare.com is not blocked by a DNS filter, hosts file, Pi-hole style blocklist or firewall.
7. Try another browser or device.
8. Turn off your VPN or proxy.
9. Switch networks, for example to a phone hotspot.

If none of that helps, the block is probably on the site's side. Cloudflare's guidance for visitors is explicit that its own staff cannot remove a challenge; only the website owner can. The same page suggests asking the owner to allow your IP address, and scanning your computer for malware and checking your antivirus or firewall if challenges follow you everywhere. Contact the site's support and include the Ray ID shown at the bottom of the challenge page and any error code from the checkbox. Those two values identify your exact request in their logs.

If you run the site: why your visitors loop

If real visitors report the loop, start from the Ray ID they send you and find that request in your Cloudflare security events, which shows which rule issued the challenge. Most loops on a site you control come from a rule that is stricter than it needs to be, or from a challenge being served somewhere it can never succeed.

• Check Challenge Passage. It lives under Security Settings in the dashboard. A very short window makes visitors re-verify constantly; Cloudflare recommends 15 to 45 minutes.
• Do not cache challenge responses. Cloudflare's error reference lists an intermediary caching the challenge as one cause of code 200100, so keep challenge pages out of any cache rule or upstream CDN.
• Do not challenge machine endpoints. APIs, webhooks and file downloads are called by clients that cannot run a challenge, so a challenge there fails every time.
• Mobile apps and WebViews need JavaScript, DOM storage and cookies enabled, access to challenges.cloudflare.com, and a user agent that does not change mid-session, per Cloudflare's troubleshooting guide.
• For your own tests, use Cloudflare's Turnstile test keys, which always pass or always fail on any domain including localhost, or allowlist your CI runners. Do not fight your own protection.

Why automation gets stuck on this page

Automated browsers fail the same check for the same reasons, only more consistently. A fresh headless browser starts with no cookies, often runs from a datacenter IP, and may report a user agent that changes between runs. Each of those makes the session look new and untrusted, so every run meets the challenge from scratch.

Before reaching for a solver, check what the request is actually getting back. Cloudflare marks every challenge response with a cf-mitigated: challenge header and a text/html body, as documented in its detection guide. If your HTTP client sees that header, you did not get the page you asked for, and retrying faster only makes the next request look worse.

One false alarm to ignore: a 401 on a request under /cdn-cgi/challenge-platform/ with pat in the path is expected. Cloudflare says it only means the device could not issue a Private Access Token, and the challenge falls back to its normal check. It is not the reason your session is stuck.

What the check looks at: IP address, user agent and JavaScript

Cloudflare does not publish its scoring, but its challenge documentation is clear that challenges run in the browser and draw on signals about the visitor. Three of them explain most automation failures:

• IP address. Reputation and network type count. Datacenter ranges and addresses shared by many unrelated clients are treated with more suspicion than a home connection.
• User agent. A user agent string such as Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/… Safari/537.36 makes a claim about the browser. If the rest of the session (headers, JavaScript features, TLS behaviour) does not match that claim, the mismatch itself is a signal.
• JavaScript challenges. The check is a script that has to run to completion. A plain HTTP client that never executes JavaScript cannot pass it at all; it needs a real browser from start to finish.

The fixes that hold up in practice are about session consistency rather than tricks:

• Persist the cookie jar between runs so a passed check is not thrown away. Our Playwright integration guide shows where storage state fits in a solving flow.
• Keep the user agent and exit IP stable for the life of the session. The clearance is bound to the visitor that earned it, so a rotating proxy pool resets it on every hop.
• Slow down. Rate limits feed the same rules that issue challenges, and Challenge Passage does not exempt you from rate limiting rules.
• For your own sites and staging environments, use the test keys or an allowlist rule described above.

When a solver helps, and when it does not

A solver helps when the page shows a Turnstile widget (the checkbox embedded in a form) on automation you are authorised to run. The widget produces a token your request submits, and that token can be generated for you if you pass the page's sitekey and URL; the captcha detector finds the sitekey on a page for you. Our Turnstile solver takes those, plus the action, cData and pageData values that challenge pages use, and returns the token with the user agent it was minted for. A full worked example is in our guide to solving Turnstile in Puppeteer.

It does not help if the underlying session is wrong. A valid token submitted from a different IP or user agent than the one it was solved for is the classic cause of rejected tokens, so pass your own proxy and replay the returned user agent exactly. And no solver should be used to get past protection on sites you are not allowed to automate; our acceptable use policy spells out where the line is.

If the site is yours, allowlisting your own automation is simpler than solving; the options are compared in captcha bypass done right. For hands-off solving while you browse, see our comparison of auto captcha solver extensions.

How CaptchaNo handles this

CaptchaNo solves Turnstile, reCAPTCHA and DataDome through one request shape on our own solving infrastructure. You send the type, page URL, sitekey and your proxy; you get back a token plus the user agent to replay. A Turnstile solve costs $0.00435, billed only when the solve succeeds. New accounts get $0.30 of free trial credit for three days, no card needed. The full request format is in the API reference, and working browser examples for Playwright, Selenium and Puppeteer are in the docs.

Frequently Asked Questions

Is "Verifying you are human" a virus or a scam?

No. It is a standard Cloudflare security page that many sites use to filter automated traffic before serving content. The real page comes from the site's own address and usually clears within a few seconds. Be suspicious only if the page asks you to paste commands, download files or enter passwords, which a genuine Cloudflare challenge never does.

How long should "Verifying you are human" take?

Cloudflare's documentation says the non-interactive check typically takes less than five seconds. Managed challenges usually pass automatically too, occasionally asking for a single click. If the page is still spinning after ten or fifteen seconds, the check is failing rather than slow, and refreshing repeatedly will not fix it.

Why do I keep getting "Verifying you are human" on every page?

The clearance cookie that proves you passed is not being kept, or it keeps getting invalidated. Browsers set to block or clear cookies, privacy extensions and VPNs that change exit address cause this. The cookie lasts thirty minutes by default, so seeing the check on every single page load points to a cookie or network problem rather than normal expiry.

Why does the check pass in a private window but not a normal one?

A private window starts with no stored cookies and usually runs with extensions turned off, so it removes the two most common causes at once. If private mode works, clear the site's cookies in your normal window, then re-enable extensions one at a time until the loop returns. The last one you turned on is the culprit.

Does a VPN cause Cloudflare verification loops?

It often does. VPN and proxy addresses are shared by many users, and some of that traffic is automated, so Cloudflare scores those addresses more cautiously. Turning the VPN off or switching to another server is one of the troubleshooting steps Cloudflare itself recommends when a challenge keeps failing.

Can a website owner turn off the check for me?

Yes, and only they can. Cloudflare states that its own staff cannot remove a challenge from a site they do not control. The site owner can adjust the rule or allowlist your address. Send them the Ray ID from the bottom of the challenge page so they can find the exact request.

Keep your automation past the check

If your authorised automation stops at a Turnstile widget, start a free CaptchaNo trial and solve it with the same proxy and user agent your session already uses. Rates for every challenge type are on the pricing page.