Cloudflare Challenge Benchmark: Browser Tools Compared

TL;DR:

• Clearing a Cloudflare challenge in production is an IP problem before it is a browser problem. A patched browser on a flagged server IP stalls on the interstitial; a real browser on clean residential egress renders the page.
• Scrapeless Scraping Browser cleared the Cloudflare challenge on 7 of 8 runs in an open, reproducible benchmark — the highest of every tool measured, and the only one that holds up when the request leaves a home IP for a datacenter one.
• Three of the four open-source browser tools tested — patchright, camoufox, and nodriver — cleared it on none of 8 runs, alongside the plain-HTTP floor; on the same target and trials, each stayed stuck on "Just a moment…".
• The one open-source tool that competed — SeleniumBase UC at 6 of 8 — only does so on a residential IP, the most favorable case for a self-hosted stack. Move to the datacenter IPs real pipelines run on and that advantage disappears.
• Every number here is reproducible. The harness is an open-source Cloudflare benchmark on GitHub: identical targets, one attempt per trial, no second attempts, one scorer for all tools. Clone it and re-run it yourself.
• Free to start. New Scrapeless accounts include free Scraping Browser runtime — sign up at app.scrapeless.com.

---

Introduction: what actually clears Cloudflare in production

Cloudflare's challenge is a rendering problem wearing a network problem's clothes. The interstitial — "Just a moment…", a spinner, "Verifying you are human" — runs a JavaScript workload and reads three signals at once: whether a real browser executes the challenge, whether the fingerprint is internally consistent, and whether the exit IP has a clean reputation. Miss any one and the page never resolves.

Most write-ups answer "how do I get past this?" with a library recommendation and a stealth plugin. That answer is testable, and it usually fails in the place it matters: a production server. A tool that clears the challenge from a laptop on home Wi-Fi behaves very differently once it runs from a cloud instance, because the exit IP flips from residential to datacenter and the reputation signal collapses.

This post measures the difference instead of asserting it. It walks through an open benchmark that runs the Scrapeless Scraping Browser against four open-source anti-detect tools and a plain-HTTP baseline, on the same Cloudflare challenge, and reports success rate, latency, and stability from raw per-trial data anyone can regenerate.

What you can measure with it

• Success rate per tool — does it render the real page, or time out on the interstitial?
• Latency of a clear — p50 and p95 of the time from request to rendered content.
• Stability across repeated runs — the spread of the success rate over trial windows, the signal for whether a tool holds up.
• Cost per successful request — bytes moved per clear against published egress rates, so a "free" tool that rarely succeeds shows its true cost.
• The IP effect — the same tools on a residential IP versus a datacenter IP, which is where production actually runs.

Why Scrapeless Scraping Browser

Scrapeless Scraping Browser is a customizable, anti-detection cloud browser designed for web crawlers and AI agents. For clearing active challenges specifically, it brings:

• Self-developed Chromium that executes the challenge JavaScript like a real browser, not an HTTP client guessing at headers.
• Residential proxies in 195+ countries as the default egress, so the reputation signal reads clean instead of datacenter-flagged — the signal that decides most challenge outcomes.
• Per-session anti-detection fingerprinting (user agent, timezone, canvas, WebGL) kept internally consistent, so the fingerprint check passes.
• Native handling of common challenge types — reCAPTCHA v2, Cloudflare Turnstile, and the Cloudflare interstitial — without a separate solver wired in.
• Session persistence that keeps a cleared session warm, so a validated session is reused instead of re-validated on every request.

Get your API key on the free plan at app.scrapeless.com.

How the benchmark measures a "clear"

Fairness is the whole point, so the rules are identical for every tool:

• One target, one definition of success. Every tool loads the same public Cloudflare challenge page and is scored by one vendor-neutral function: the page is cleared only when the interstitial title flips to the real page title and content renders. "Just a moment…" is a fail, and so is a page that never leaves the spinner.
• One attempt per trial, no second chances. No tool gets a second allocation or a re-connect loop to hide a bad run. This mirrors how a single production request behaves and keeps the comparison honest — a second-attempt budget would flatter every tool unequally.
• One timeout for everyone. The same wall-clock ceiling applies across the field, so a tool that "succeeds" after two minutes of grinding is scored the same way a real pipeline would score it.
• Cost measured, not asserted. Wire bytes per successful clear are captured client-side and multiplied by each tool's published egress rate. Open-source tools on their own IP move bytes for free — but a tool that rarely clears has a punishing cost per success, which the raw rate hides.

The field: the Scrapeless Scraping Browser; nodriver, patchright, camoufox, and SeleniumBase (undetected mode) as the open-source browser tools; and a plain-HTTP client as the floor. The automated-threat vocabulary these challenges are built to stop is catalogued in the OWASP Automated Threats to Web Applications project, and the three signals map cleanly onto it: the TLS handshake described in the TLS 1.3 specification, the browser fingerprint, and the clearance cookie set per the HTTP State Management spec. Cloudflare's own description of the challenge types it serves lives in the Cloudflare challenge documentation.

Get your API key on the free plan: app.scrapeless.com

Results on a residential IP (the open-source tools' best case)

Run from a residential IP — the most favorable egress a self-hosted tool can have — the field splits cleanly. Eight trials per tool, one attempt each, identical timeout:

Ratings use a four-level scale over eight trials: Very High = 7–8/8 cleared · High = 5–6/8 · Medium = 3–4/8 · Low = 0–2/8. Exact per-trial counts are in the benchmark's results table so every rating traces back to the run.

Tool	Cleared the challenge	Notes
Scrapeless Scraping Browser	Very High	highest in the field; cleared the challenge on nearly every trial
SeleniumBase (undetected mode)	High	the only open-source tool that competes — on this residential IP
patchright	Low	faced the challenge on every run, cleared none
camoufox	Low	faced the challenge on every run, cleared none
nodriver	Low	faced the challenge on every run, cleared none
plain HTTP (floor)	Low	403 on every request

Two things stand out. First, even on the turf that favors a self-hosted stack most, the Scrapeless Scraping Browser leads the field and clears more consistently. Second, "use an anti-detect browser" is not a complete answer: three of the four open-source browser tools cleared the challenge zero times, and did not fail fast — they held the interstitial until the timeout.

The datacenter IP is the production story

Residential Wi-Fi is not where scrapers run. Production pipelines run on cloud servers, and a cloud server exits through a datacenter IP that Cloudflare's reputation signal treats very differently. That single change is what separates the field.

Measured in CI (datacenter IP, GitHub Actions), same target, same eight trials per tool, same one-attempt rule:

Tool	Cleared the challenge	p50	p95	Mean KB / clear	$/1k success	Stability σ
Scrapeless Scraping Browser	High	14,274 ms	26,009 ms	153.9	$0.063	43.3%
seleniumbase-uc	Low	58,993 ms	65,390 ms	—	—	—
camoufox	Low	56,574 ms	59,348 ms	—	—	—
patchright	Low	51,920 ms	52,302 ms	—	—	—
nodriver	Low	51,830 ms	52,886 ms	—	—	—
plain HTTP (floor)	Low	100 ms	254 ms	—	—	—

The residential 6-of-8 that SeleniumBase (undetected mode) posted has nothing to stand on here — on the datacenter IP it cleared the challenge zero times, and the p50/p95 columns show why: every open-source browser tool spent roughly 52–65 seconds per trial grinding on the interstitial before the timeout fired, then returned nothing. The plain-HTTP floor "fails fast" at a 100 ms p50 because it never runs the challenge at all — it takes the 403 and exits. Cost and byte columns are blank for the 0% tools because there is no successful clear to divide bytes or dollars into; a "free" tool with no clears has an undefined cost per success, not a cheap one.

On a datacenter IP the self-hosted tools lose the one advantage they had — a clean residential exit — because they have no clean egress of their own to fall back on. The Scrapeless Scraping Browser is unaffected in kind: it still clears the challenge because its requests exit through residential proxies regardless of where the benchmark process runs, landing at 6 of 8 (High) with a 14.3-second p50 and a measured $0.063 per thousand successful clears. The result is the version of this test that matches production — only the tool that brings its own residential egress keeps clearing the challenge, and it does so while the rest of the field returns 0%.

That is the honest case for a managed cloud browser. It is not that open-source tools can never clear Cloudflare — one of them can, on the right IP. It is that reliability in the environment you actually deploy to is the property that survives, and that property comes from egress and consistency, not from a stealth patch.

How to read this for your own stack

• If you run on a laptop or a residential proxy already, and volume is low, a self-hosted undetected browser can work — accept the maintenance and the run-to-run variance.
• If you deploy on cloud servers, need consistency, or run at any real concurrency, the egress reputation problem is the wall, and a cloud browser that ships its own residential exit is the path that holds. Compare the pricing against the engineering time a self-hosted stack costs to keep alive.
• Either way, measure it on your target. The challenge page used here is a public practice target; your site may sit behind a stricter configuration. The harness is built to point at whatever you need to test.

For the mechanics of driving the cloud browser — session creation, proxy country, and reading the rendered DOM — the Scraping Browser docs cover the full flow, and the anti-bot approach is unpacked further in the sibling guide on clearing Cloudflare protection and Turnstile.

Conclusion: reliability is an egress property

Clearing Cloudflare in production reduces to three signals — a real browser, a consistent fingerprint, and a clean exit IP — and the third one is where self-hosted stacks quietly break. On a residential IP the field looks competitive; on the datacenter IP real pipelines use, it does not. The Scrapeless Scraping Browser cleared the challenge most often and most consistently, and it is the only tool measured whose success does not depend on where the process happens to run. The numbers are not a claim to trust — they are a harness to run. Pin US residential egress, keep the session warm by loading the site once before the target page, keep concurrency modest per host, and let the measured success rate settle the argument.

---

Ready to clear Cloudflare in production?

Join our community to claim a free plan and connect with developers building anti-bot-resistant pipelines: Discord · Telegram.

Sign up at app.scrapeless.com for free Scraping Browser runtime and point the benchmark at the Cloudflare-protected pages your pipeline needs.

FAQ

Q: Do I need a proxy to clear the challenge?
Yes — clean egress is the signal that decides most outcomes. The Scrapeless Scraping Browser uses US residential proxies by default; a self-hosted tool needs its own residential egress, and on a datacenter IP without one, the challenge rarely clears.

Q: The page shows "Just a moment…" or Access Denied. How do I get a clean render?
Pin US residential egress and warm the session first: load the site's homepage in the same session before requesting the target page, so the clearance cookie is set on a validated session. Keep concurrency modest — three workers per host is a safe ceiling for parallel runs.

Q: Why do open-source tools clear the challenge on my laptop but fail on my server?
Your laptop exits through a residential IP; your server exits through a datacenter IP with a worse reputation. Same tool, same code — the exit IP changed, and that is the signal Cloudflare weighs most heavily. It is the single biggest reason a stack that works in testing fails in production.

Q: Can the open-source tools ever clear it?
Yes — SeleniumBase in undetected mode cleared the challenge on a residential IP in this benchmark. The point is not that self-hosted tools never work; it is that their success depends on an IP condition production usually removes, plus ongoing maintenance as the tools and the challenge both change.

Q: How do I reproduce these numbers?
The harness is an open-source Cloudflare benchmark on GitHub. Clone it, install the tools, set a Scrapeless API key, and run the same matrix — same targets, same trials, same one-attempt rule. It writes a results table plus raw per-trial JSON, so every figure traces back to the run that produced it, and the datacenter-IP numbers come straight from its GitHub Actions run.