How to Bypass Cloudflare Turnstile in 2026

A Cloudflare Turnstile bypass almost never fails at the checkbox. By the time a checkbox appears, Turnstile has already scored your browser, your TLS handshake and your IP, and decided you deserve a second look. Plenty of scrapers stuck on Cloudflare are also working on the wrong problem, because the page stopping them is a challenge interstitial or a firewall rule, and no Turnstile method touches either one. Figure out which response you are getting first, then pick the method that fits it.

The short answer: run a patched browser such as SeleniumBase UC Mode, Camoufox or CloakBrowser on a clean mobile IP, keep that IP for the whole session, and let Turnstile's own scripts pass instead of faking a token. Solver services only help on standalone form widgets, and no browser setup lifts a WAF block.

Which Cloudflare Block Are You Getting?

"How to bypass Cloudflare" is really three questions, because Cloudflare responds to suspicious traffic in three distinct ways. Treating them as one problem is why a fix that works on one site does nothing on the next.

Turnstile proper is the widget. Sites embed it in a login, signup or checkout form, and the form only goes through when it carries a valid token in the cf-turnstile-response field.

Challenge pages sit in front of the whole site. Cloudflare serves one in place of the origin response, and passing it earns a cf_clearance cookie. Under the hood it runs the same Turnstile technology, which is why the two get mixed up so often.

A WAF block is a rule the site owner wrote: a blocked country, a banned ASN, a rate limit, a flagged User-Agent. Nothing you solve on your side lifts it.

Cloudflare gives you a clean way to spot the middle case. Every challenge page response carries a cf-mitigated: challenge header, according to Cloudflare's challenge docs. The script below sorts any URL into one of the three buckets.

1
import requests
2

3
PROXY = "http://<list-username>:<list-password>@proxy.voidmob.com:10000"
4

5
def classify(url):
6
  r = requests.get(url, proxies={"http": PROXY, "https": PROXY}, timeout=30)
7
  body = r.text
8
  server = r.headers.get("server", "").lower()
9

10
  if r.headers.get("cf-mitigated") == "challenge":
11
      return "Challenge page: needs a real browser to earn cf_clearance"
12
  if "1020" in body and "Access denied" in body:
13
      return "WAF block (1020): a site rule, nothing to solve"
14
  if r.status_code == 403 and "cloudflare" in server:
15
      return "Cloudflare 403: firewall, IP or rate rule"
16
  if "cf-turnstile" in body or "challenges.cloudflare.com/turnstile" in body:
17
      return "Turnstile widget: token needed when the form submits"
18
  return f"No Cloudflare block detected (HTTP {r.status_code})"
19

20
print(classify("https://target-site.com/login"))

Expect a plain requests call to get challenged on protected sites, since its TLS fingerprint looks nothing like a browser. That is fine here. You only want to know what kind of response you are dealing with before spending hours on the wrong fix.

How Turnstile Scores You Before Any Checkbox

Site owners pick one of three widget modes, per Cloudflare's widget documentation: Managed, Non-Interactive and Invisible. Managed is the recommended default and the only mode that can ever show a checkbox, and it shows one only when the visitor looks risky. Non-Interactive displays a spinner. Invisible displays nothing at all. Several popular bypass tutorials get this wrong, listing an "Interactive" mode that does not exist and describing Managed as invisible.

So the checkbox is a consequence of a bad score, not the test itself. Before it ever renders, Turnstile runs JavaScript probes in the page (canvas, WebGL, available browser APIs, automation flags), a proof-of-work computation, and network checks such as IP reputation and whether your TLS fingerprint matches the browser your User-Agent claims to be. Our JA3 vs JA4 breakdown covers that last check in detail.

What comes out the other end is a token, and its limits matter more for a bypass than anything about the checkbox. From Cloudflare's server-side validation docs and its Challenge Passage settings:

Behind the form, the site's backend posts each token to Cloudflare's Siteverify endpoint, optionally along with the visitor's IP, and gets back the hostname and action the token was issued for. A token replayed on a retry or submitted after five minutes fails right there, however clean your client-side flow looked. One solved on a different page fails too once the backend checks the returned hostname and action against what it expects, as Cloudflare recommends.

Cloudflare Turnstile Bypass Methods and Where Each Fails

Patched Browser on a Dedicated Mobile Proxy

This is the setup that holds up best, because it cleans both halves of the score at once. On the browser side, SeleniumBase in UC Mode, Camoufox (a patched Firefox with a Playwright-style API) and CloakBrowser (patched Chromium) let Turnstile's own scripts run and pass, because the automation traces are removed at the driver or engine level instead of papered over with injected JavaScript. Stock headless Chrome and the old puppeteer-extra stealth plugin mostly do not. SeleniumBase also ships a helper that clicks the checkbox with OS-level mouse input if Managed mode escalates.

On the network side, a dedicated mobile proxy gives that browser a real 4G/5G carrier IP that no other proxy customer shares, on a physical device with a mobile ASN (and the carrier's own DNS on the standard tier). IP reputation usually comes back clean and the network layer agrees with a real device before the checkbox logic even runs. Put a clean browser on a clean carrier IP and Managed mode has very little reason to escalate. The same pairing carries over to DataDome, Akamai and most other anti-bot stacks, since they score the same two layers.

Where it fails: headed browsers eat CPU and memory, so hundreds of parallel sessions mean real hardware. Fingerprint consistency becomes your job too, and small mismatches drag the score down fast: a Windows User-Agent reporting Linux fonts, or a timezone that disagrees with the IP location. No proxy fixes a browser that leaks navigator.webdriver; the carrier IP just gets flagged along with it. Run each profile through our fingerprint test before pointing it at a target.

Do Turnstile Solvers Like 2Captcha Work?

Services such as 2Captcha and CapSolver take the sitekey (from the widget's data-sitekey attribute) plus the page URL, solve Turnstile on their own machines, and hand back a token. You drop it into cf-turnstile-response and submit.

For a standalone widget on a form, submitted quickly, this works. It breaks when the token lands after the 300 second window, when your retry logic resends the same token, or when the target is a challenge page. Clearance on a challenge page belongs to the browser that solved it: per Cloudflare's clearance docs, the cf_clearance cookie is tied to the specific visitor and device it was issued to, which prevents reuse across machines. Every solve also adds seconds of latency and a per-solve fee.

Managed Unblocker APIs

Unblocker and cloud browser APIs from scraping vendors take care of the browser, fingerprint and challenge, and return HTML. For low volume with no appetite for maintenance, they are a reasonable choice. You pay per request, you get no control over the session, and when a target changes you wait on someone else's fix. Logged-in flows that need one stable identity fit them poorly.

Cloudflare Turnstile Bypass with Playwright

Stock Playwright Chromium exposes enough automation signals that Managed mode tends to escalate or loop. Swap in a patched build (Patchright, Camoufox's Playwright interface, or CloakBrowser), run headed where you can, and let the Turnstile iframe from challenges.cloudflare.com finish loading before you interact with anything. Client Hints and device emulation still need patching at the CDP level, and the full config lives in our Playwright proxy setup for Cloudflare.

Why Rotating IPs Makes Turnstile Worse

Standard scraping advice says rotate IPs to spread the load. Against Turnstile that advice backfires twice.

Clearance lives in the session. Your cf_clearance cookie stays valid for the Challenge Passage period the site sets, 30 minutes unless the owner changed it. Switch IPs halfway through and the cookie usually stops being honored, so every rotation buys you a fresh challenge.

Turnstile can also follow the device instead of the address. Ephemeral IDs are short-lived device identifiers generated on each solve, and Cloudflare built them specifically to catch attackers who change IP addresses between requests. They are Enterprise-only, so most sites do not have them. The sites people struggle with most are often exactly the ones paying for Enterprise, though, and there a hundred IPs behind one browser profile read as one device doing a hundred odd things.

IP type matters inside that model. Mobile carrier IPs sit behind CGNAT, shared by many real phone users at the same time, so blocking one means blocking real customers and reputation systems are slow to burn them. That keeps Managed mode on its quiet path more often than a datacenter IP will. Paired with a sticky session, a mobile IP also gives the browser one stable address for as long as clearance lasts.

Mobile is not required everywhere. On lightly protected targets, residential IPs pass Turnstile fine and cost less per GB. If the challenge keeps looping on a clean mobile IP, look at the browser, not the proxy.

Before blaming the target, check how your own connection reads:

For long sessions on one identity, a dedicated device with manual IP changes is the right fit. For high-volume jobs where each profile lives briefly, rotating mobile proxies with sticky sessions work well, as long as rotation happens between profiles and never inside one.

Getting Past a Cloudflare 403 or IP Ban

A 403 with no cf-mitigated header, or an Error 1020 page, means a firewall rule matched. There is no token to earn, only a rule to satisfy, so work out what it keys on:

• Country block: an IP in an allowed country clears it.
• ASN or hosting-range block: a residential or mobile IP clears it, since the rule targets datacenter ranges.
• Rate limit: slow down. Challenge Passage does not apply to rate limiting rules, so a valid cf_clearance will not save you.
• Browser signature rule (Error 1010): only a real browser signature passes, not a spoofed header.

Banned on one specific IP? Any clean replacement clears it, but fix whatever triggered the ban first, or the new address goes the same way. And if the rule blocks a path for everybody, no proxy on earth helps.

Stuck in a Verify Loop as a Regular User

If you are just trying to open a website and the human check keeps coming back, Cloudflare's own troubleshooting guidance is short. Make sure your browser is current and JavaScript is enabled, and check that a VPN, proxy, or an ad-blocking or privacy extension is not blocking the challenge scripts. A private window or a different network narrows down the cause. If none of that works, Cloudflare's advice is to contact the website's administrator with the error code and Ray ID. Challenge settings belong to the site owner, who can, for example, allowlist your IP.

FAQ

Clean Browser, Clean Carrier IP

Start with the classifier. If it reports a WAF block, change whatever the rule keys on (IP, country or request pace), because there is nothing to solve. If it reports a Turnstile widget or a challenge page, run a patched browser on a dedicated mobile IP, check the profile in the fingerprint test, and hold that one IP until clearance expires. Then retire the profile and the IP together, and start the next session fresh.