TL;DR
- FlareSolverr wins when you need a free relay to clear simple Cloudflare challenges at low volume.
- curl_cffi wins for TLS/JA3-fingerprinted APIs that return JSON without needing a real browser.
- Camoufox wins for JS-rendered sites that detect headless browsers and inspect fingerprints closely.
- SeleniumBase wins if you already run Selenium and want stealth patches plus CAPTCHA helpers built in.
- undetected-chromedriver still works on existing setups, but its releases stalled in 2024, so treat it as legacy.
- Residential proxies solve IP reputation, but never fingerprint or behavioral detection on their own.
- Scrapfly, ZenRows, and Context.dev win when CAPTCHA-heavy targets and scale make maintenance the real cost.
Self-hosting wins at low volume and simple targets where you want full control. Managed APIs win once fingerprint patching and proxy funding outpace the value of the data. The table below maps each tool to its layer.
Python anti-bot tools compared
The table splits into two groups. Self-host rows (FlareSolverr, Camoufox, SeleniumBase, curl_cffi, undetected-chromedriver) hand you the code and the maintenance. Managed API rows (Scrapfly, ZenRows, Context.dev) absorb the fingerprint and proxy upkeep behind an endpoint. Residential proxies sit underneath every other row as a network-layer dependency, not a standalone defense.
| Tool | Type | What It Defeats | Setup Effort | Best For |
|---|---|---|---|---|
| FlareSolverr | Library (self-host) | Cloudflare JS challenges | Low | Free challenge-solving relay for simple Cloudflare pages |
| Camoufox | Library (self-host) | Browser fingerprint, headless tells | Medium | Deep Firefox-level stealth without a commercial API |
| SeleniumBase (UC and CDP Mode) | Library (self-host) | Headless tells, some CAPTCHA | Medium | Teams already on Selenium wanting built-in stealth patches |
| curl_cffi | Library (self-host) | TLS/JA3 and HTTP/2 fingerprint | Low | Fast TLS-matched requests against JSON APIs, no browser |
| undetected-chromedriver | Library (self-host) | Headless tells | Medium | Existing deployments only; releases stalled since 2024 |
| Residential proxies | Infrastructure | IP reputation, rate limits | Medium | Network-layer IP rotation feeding any tool above |
| Scrapfly | Managed API | IP reputation, TLS/JA3, headless tells, anti-bot vendors | Low | Broad anti-bot bypass with scraping-specific tooling |
| ZenRows | Managed API | IP reputation, TLS/JA3, headless tells, anti-bot vendors | Low | Stealth browser sessions plus premium-proxy auto-rotation |
| Context.dev | Managed API | IP reputation, TLS/JA3, headless tells, CAPTCHA | Low | Single-endpoint LLM-ready output with no proxy or fingerprint upkeep |
Read the "What It Defeats" column as a stack, not a menu. No single self-host library covers all four detection layers, which is why real setups chain a proxy pool, a fingerprint tool, and a CAPTCHA solver together. Managed rows collapse that chain into one call. The rows below break down each tool, and the four-layer detection model further down explains why coverage across all four layers matters.
FlareSolverr
FlareSolverr is the free way to get past Cloudflare's JavaScript challenge when you don't want to build browser automation yourself. You run it as a local proxy service on port 8191, and it drives a real Chrome instance in the background to solve the challenge, grab the cf_clearance cookies, and hand them back to your scraper. Notably it does not run headless, because headless mode is itself detected. On Linux it starts Xvfb and runs Chrome head-full on a hidden virtual display. Your existing HTTP client points at the FlareSolverr endpoint instead of the target site, and the challenge-solving happens transparently.
That relay design is why teams reach for it first. You keep your fast HTTP-based scraper and offload only the challenge step, so you avoid running a full browser for every request.
The ceiling is maintenance and scope. Cloudflare updates its challenge logic regularly, and each change can break FlareSolverr until the community ships a patch. The project is still maintained, despite a fair number of blog posts claiming otherwise, but the cadence is thin and it went eleven months between releases across 2024 and 2025. Turnstile is the harder limit: the project's own README states that none of the CAPTCHA solvers currently work, so treat FlareSolverr as a JS-challenge relay rather than a CAPTCHA answer. For low-volume scraping against Cloudflare-protected pages it works well. At scale, or against sites that layer TLS fingerprinting on top, you outgrow it.
Camoufox
Camoufox is a Firefox fork that spoofs fingerprints at the browser engine level, which puts it ahead of patched Chromium tools for anyone who needs deep stealth without paying for a commercial API. Instead of patching a handful of headless tells after the fact, it intercepts calls in the browser's C++ implementation, so the hijacked properties appear native under inspection. WebGL, fonts, navigator properties, screen geometry, and audio come from a coherent spoofed profile rather than a Chromium build with obvious signatures.
That coherence is the reason to pick Camoufox over undetected-chromedriver. Patched Chromium tools inherit Chromium's fingerprint surface and race detection vendors who know exactly what a headless Chrome looks like. Camoufox starts from Firefox, a smaller target for those vendors, and rewrites the values that usually give automation away. It also patches Firefox's Juggler protocol to sandbox Playwright's page agent, which closes a tell that plain Playwright leaves open.
Reach for Camoufox when your targets fingerprint aggressively and you need full control over the browser without a managed subscription. If you are already committed to Chrome-based tooling or your targets barely check fingerprints, SeleniumBase in CDP Mode is the lighter choice.
SeleniumBase (UC and CDP Mode)
SeleniumBase makes sense when your team already writes Selenium tests and doesn't want to abandon that stack to add stealth. Its UC Mode patches the driver so a Chrome session stops leaking the obvious tells that Cloudflare and DataDome watch for, and it ships a helper that clicks Cloudflare Turnstile and reCAPTCHA checkboxes for you. You keep the familiar Selenium API and get the stealth layer bolted on top.
UC Mode automates the parts most teams get wrong by hand. It renames the cdc_ DevTools variables that chromedriver injects into the page, disconnects and reattaches the driver around stealthy actions so detection scripts find no automation hooks mid-navigation, and drives the CAPTCHA click through simulated cursor movement rather than an instant programmatic click.
Note that SeleniumBase now positions CDP Mode as UC Mode's successor. UC Mode is not deprecated and still works, but new projects should start on CDP Mode, which drives the browser over the Chrome DevTools Protocol without a WebDriver attached for most of the session.
What neither mode does is tune itself to your target. You still set realistic delays, manage your own residential proxies, and adjust timing when a specific site flags your session. The stealth patches get you past the generic checks. The site-specific behavioral tuning stays your job.
curl_cffi
curl_cffi wins when your target checks the TLS handshake but never needs a rendered page. The library impersonates the JA3 and HTTP/2 fingerprints of real browsers like Chrome and Safari at the network layer, so a plain HTTP request looks like it came from a genuine browser client. You skip launching a headless browser entirely, which cuts request latency to a fraction of what Selenium or Playwright spend spinning up Chromium.
That speed advantage is the whole point. A single machine can push thousands of curl_cffi requests where a browser-based approach would need a fleet, and your compute bill drops accordingly. For JSON APIs and static HTML behind TLS-based bot walls, nothing else on this list touches its throughput per dollar. It is also the most actively maintained library in this comparison, which matters for a tool whose entire job is tracking what real browsers currently send.
The approach fails the moment the page depends on JavaScript. curl_cffi sends and receives raw bytes, so any content rendered client-side or gated behind a JS challenge stays invisible to it. For those targets you need a real browser like Camoufox, or a managed API that renders JavaScript for you.
undetected-chromedriver
undetected-chromedriver patches a standard Chromium build to strip the signals that expose automation. It removes the navigator.webdriver flag, adjusts the browser's automation properties, and mimics the launch profile of a real Chrome install, so a JS-heavy page that would block a raw Selenium session often lets undetected-chromedriver through. For years it was the default pick for JS-rendered targets that check for a headless browser.
The problem in 2026 is that the project has effectively stopped moving. The last PyPI release, 3.5.5, shipped in February 2024, and the repository has taken roughly two commits since, against more than a thousand open issues. It is not formally archived, and existing deployments still work, but a stealth library only stays useful while someone keeps pace with the detection vendors it is hiding from. That work is not happening here.
Keep undetected-chromedriver if you already run it and your targets have not tightened their checks. For anything new, start on SeleniumBase in CDP Mode, nodriver from the same author, or Camoufox. All three are actively maintained, and the migration cost now is smaller than the cost of discovering the gap when a target site updates.
Residential proxies
Residential proxies solve one problem well, and it is the one every other tool on this page still leans on. They route your requests through real consumer IP addresses, so anti-bot systems checking IP reputation see a household connection instead of a datacenter range. That defeats the crudest filter, IP-based rate limits and blocklists, and buys you the address diversity that rotation strategies depend on.
Proxies never solve fingerprint or behavioral detection on their own. A residential IP tells the server where your request appears to come from, but it says nothing about your TLS handshake, your headless browser tells, or your click timing. Send a datacenter-grade JA3 signature from a residential IP, and a modern anti-bot vendor flags the mismatch immediately.
Treat proxies as the network layer of a stack, not a standalone bypass. curl_cffi handles the TLS layer, Camoufox and the Chromium-based tools handle the browser layer, and residential IPs sit underneath all of them. Rotation stopped working alone because detection moved up the stack, a shift the next sections trace in detail.
Scrapfly
Scrapfly handles the anti-bot stack for you through a single scraping API, and it covers the same detection layers most self-hosted tools force you to stitch together. It rotates residential proxies across 190+ countries, matches JA3 and JA4 TLS fingerprints, renders JavaScript, and bypasses the major anti-bot vendors behind one request, so you skip the maintenance treadmill that breaks patched Chromium builds every time a vendor updates its challenges.
Its real advantage over a raw library is the scraping-template ecosystem. Scrapfly ships extraction rules, persistent sessions that hold cookies and a sticky proxy IP together, and screenshot tooling aimed squarely at people building traditional scrapers, which makes it a strong pick if your job is pulling HTML from difficult targets at scale.
Where it diverges from Context.dev is the shape of the output and the use case. Scrapfly optimizes for scraping workflows and returns raw page content you then parse yourself. Context.dev optimizes for LLM and agent pipelines, returning clean Markdown or structured JSON from a single endpoint with MCP integration, so the data drops straight into a model context without a parsing step. Pick Scrapfly when you want scraping-specific tooling and control over extraction logic. Pick Context.dev when your downstream consumer is an agent that needs ready-to-use structured output.
ZenRows
ZenRows pairs a stealth browser with premium residential proxies behind a single scraping API, and it handles JS rendering and proxy auto-rotation for you. Its Browser Sessions product, formerly marketed as Scraping Browser, drives a real browser you control remotely, while the Premium Proxy feature routes requests through residential IPs and rotates them automatically instead of asking you to manage a pool. For teams scraping protected sites at scale, that removes most of the network and browser maintenance covered earlier on this page.
Where ZenRows differs from Context.dev is the shape of its output. ZenRows returns HTML or a JSON scrape result you still parse and clean before feeding it to a model. Context.dev returns LLM-ready Markdown or structured JSON from one endpoint, so an agent consumes it directly with no post-processing step. If you are building an LLM pipeline and want clean structured content rather than raw page HTML, that difference decides the fit.
Pick ZenRows when you want a proven managed proxy-and-browser combination and control over how you parse the response. Pick Context.dev when you want the same anti-bot handling but need the output already shaped for an LLM or agent through MCP.
Context.dev
Context.dev handles every detection layer through one endpoint, so you never fund a proxy pool or patch a fingerprint yourself. You send a URL and get back clean Markdown or structured JSON, and the proxy rotation, TLS matching, browser fingerprinting, and CAPTCHA handling all happen on our side. The self-hosted tools above each solve one or two layers and leave you responsible for the rest.
The maintenance cost is what disappears. With a patched Chromium build or FlareSolverr, you track detection-vendor updates and patch when they break, and this year's stalled undetected-chromedriver releases are a fair illustration of what happens when that upkeep stops. You also budget separately for residential proxies and often a CAPTCHA-solving service on top. Context.dev folds all of that into a single bill with no credit multipliers, and there is no infrastructure for you to run.
For teams building AI agents or LLM pipelines, the output matters as much as the bypass. Context.dev returns LLM-ready structured data directly, and the MCP integration lets an agent pull live web content without a scraping layer of its own. That makes it the fastest way to replace an internal crawler with a managed service.
The trade-off is control. You get less low-level access to individual requests, headers, and browser flags than you would running Camoufox or SeleniumBase yourself. When that granular control genuinely matters, self-hosting can still win, which the next section covers directly.
The four layers of bot detection
Modern anti-bot systems inspect requests at four distinct layers, and each layer catches a different class of automation. A tool that beats one layer says nothing about the other three, which is why a stealth browser still gets blocked behind a datacenter IP and a rotating proxy still gets flagged by its TLS handshake. Read the "what it defeats" column in the table as a map of which layer each tool covers, not as a ranking of quality.
The network layer checks where the request comes from. Detection here scores your IP against known datacenter ranges, request rate, and reputation history. Residential proxies address this layer and nothing else. They give you a clean IP with real ISP reputation, but the request they carry still exposes every fingerprint above them.
The TLS-JA3 layer inspects how your client negotiates the encrypted connection. Every HTTP library produces a distinctive JA3 hash from its cipher order and extensions, and Python's default clients look nothing like Chrome. curl_cffi solves this layer by impersonating a real browser's handshake, which is why it defeats fingerprinting no proxy can touch.
The browser fingerprint layer runs JavaScript to interrogate the client after the connection opens. It reads canvas rendering, WebGL, navigator properties, and the automation flags that headless Chrome leaks. Camoufox, undetected-chromedriver, and SeleniumBase all patch these tells, each with a different depth of coverage. curl_cffi fails here completely because it never executes the JavaScript that does the probing.
The behavioral layer watches what you do after you load the page. It scores mouse paths, scroll timing, and click cadence against human patterns, and it is what decides whether you see a challenge at all. No self-hosted tool solves this cleanly, which is why SeleniumBase ships click helpers and why managed APIs fold behavioral handling into the request itself.
Stacking these layers explains the table. FlareSolverr and the browser tools cover the middle. Proxies cover the bottom. Only the managed rows cover all four in a single call.
Why proxy rotation alone stopped working
Rotating proxies stopped working because anti-bot vendors moved detection past the IP layer. For years, a fresh residential IP was enough to get past a rate limit or a reputation block, and rotation solved almost every access problem. Cloudflare, Akamai, and DataDome then started inspecting the request itself, not just where it came from. A clean IP now fails the moment the TLS handshake or browser fingerprint doesn't match a real user.
The shift happened at the TLS layer first. When your Python client opens an HTTPS connection, it sends a specific set of ciphers and extensions that produce a JA3 fingerprint. A default requests or urllib3 client produces a fingerprint no real Chrome or Firefox ever generates, and detection vendors flag it before your code sends a single header. Perfect proxy rotation cannot hide a handshake that screams "Python."
Above TLS, the vendors added browser fingerprinting. A headless Chrome instance leaks dozens of tells through its JavaScript environment, from navigator.webdriver to canvas and WebGL rendering quirks. Residential proxies do nothing about any of these, because the fingerprint travels inside the browser, not the network path.
Fingerprinting and TLS-matching tools became additions to proxies, not replacements for them. You still need a trusted IP to clear the network layer, and curl_cffi or a patched browser handles the layers a proxy never touched. A residential proxy behind a Python client with a broken JA3 fingerprint still gets blocked, and a perfect fingerprint from a blacklisted datacenter IP gets blocked too. Modern access requires every layer to look human at once, which is why the single-tool approach collapsed.
CAPTCHA solving: services vs. DIY
CAPTCHA solving splits into two paths, and cost-per-solve decides which one you pick. Third-party services like 2Captcha and CapMonster route the challenge to a solver farm or a trained model and return a token your scraper submits. Published rates run roughly $0.60 to $3.00 per thousand solves depending on the service and the challenge type, with reCAPTCHA v2 at the cheaper end and enterprise variants at the top. You pay per solve, but you skip the engineering entirely.
The DIY path uses audio transcription for reCAPTCHA audio challenges, vision models for image grids, or click simulation that mimics human mouse movement. Whisper-style transcription handles audio reasonably well, and open vision models can classify image tiles. Both break the moment the CAPTCHA vendor changes its challenge design, and you inherit that maintenance forever. For a hobby scraper hitting one target, DIY costs nothing but your time. At scale, the per-solve fee of a service beats the engineering hours you would spend chasing model accuracy. Our breakdown of how CAPTCHA solvers work covers the reliability trade-offs in more depth.
Reliability is the second deciding factor, and it favors fixing your fingerprint over buying solves. hCaptcha scores passive signals like IP reputation, dwell time, and mouse movement, then decides whether to show a visual challenge at all, so a session that already looks automated draws harder challenges. reCAPTCHA v3 goes further and never shows a challenge: it returns a score for every request and leaves the site owner to decide what to do with it, which means no solving service can help you once your score is low. In both cases the challenge is a symptom of an upstream fingerprint or behavior problem.
Managed anti-bot APIs fold both problems into one bill. Scrapfly, ZenRows, and Context.dev handle the anti-bot layer behind their endpoints, so you never contract a separate solver or track its accuracy. With Context.dev, one request returns the rendered content, and CAPTCHA handling sits inside that call rather than as a vendor you fund and monitor on the side.
Self-host vs. managed: the decision framework
Three variables decide whether you self-host or buy a managed API: request volume, target complexity, and how much low-level control you need. Score each one honestly before you commit to an architecture, because the maintenance curve punishes the wrong choice at scale.
Self-hosting wins at low volume against simple targets. If you scrape a few thousand pages a day from a handful of sites behind basic Cloudflare, FlareSolverr as a relay or curl_cffi for TLS-matched requests costs nothing and gives you full control over every header and timing decision. Camoufox and SeleniumBase extend that reach when you need real browser stealth, and at this scale the occasional afternoon spent repatching after a Cloudflare update stays cheap. Our guide to Python scraping libraries covers the extraction side of that stack.
The curve tips when your target list grows and your sites fight back. Every self-hosted tool on this page depends on residential proxies you fund and rotate separately, fingerprint patches you track against detection-vendor updates, and CAPTCHA handling you either build or wire to a third party. Run that across dozens of sites at millions of requests and the maintenance stops being an afternoon. It becomes a standing engineering cost that competes with the work you actually shipped the scraper to do. It also carries a concentration risk, since a library that looks healthy today can go quiet, as undetected-chromedriver users found out.
A managed API like Context.dev absorbs those three cost centers behind one endpoint. You stop funding a proxy pool, stop tracking fingerprint patches, and stop contracting a separate CAPTCHA vendor, and you get clean structured output that drops straight into an LLM pipeline through MCP. The honest trade-off is control. You give up header-level and timing-level tuning that self-hosting hands you outright.
Pick self-hosting when volume is low, targets are simple, and you need that low-level control. Pick a managed API when target complexity and scale turn maintenance into a full-time tax you would rather not pay.
FAQs
What's the best free tool for bypassing Cloudflare? FlareSolverr handles most Cloudflare JavaScript challenge pages by running a real browser as a local proxy your scraper routes through. It works well for low-volume, simple targets, though its own documentation notes that its CAPTCHA solvers do not currently clear Turnstile. Context.dev is the managed alternative once Cloudflare's challenge updates make the maintenance too costly to track.
Do I still need residential proxies with a managed anti-bot API? No, a managed API like Context.dev includes its own proxy layer, so you don't fund or rotate a separate pool. Context.dev folds IP reputation, fingerprint spoofing, and TLS matching into a single endpoint, which removes the proxy-management line item entirely. That consolidation saves you from stitching a proxy vendor onto your stack yourself.
Can curl_cffi replace a headless browser? Only for targets that don't require JavaScript execution, since curl_cffi impersonates browser TLS and HTTP/2 fingerprints without rendering a page. It defeats JA3 fingerprinting cheaply, and Context.dev covers the JS-heavy targets where curl_cffi has nothing to render. Use curl_cffi when raw speed on API-style endpoints matters more than full page rendering.
Is undetected-chromedriver still safe to use in 2026? It still runs, but its last release was in early 2024 and development has largely stopped, so it no longer keeps pace with detection-vendor updates. Existing deployments against unchanged targets are fine for now. For new work, use SeleniumBase in CDP Mode, nodriver, or Camoufox instead.
How much does CAPTCHA solving typically cost per request? Published rates at 2Captcha and CapMonster run roughly $0.60 to $3.00 per thousand solves depending on the service and the CAPTCHA type. Context.dev absorbs CAPTCHA handling into its per-request pricing, so you avoid a separate solver contract and its per-solve billing. The benefit is a single predictable cost instead of two vendors to reconcile.
When does self-hosting stop being worth it? Self-hosting stops paying off once patch maintenance across FlareSolverr, Camoufox, and SeleniumBase consumes more engineering time than the volume justifies. Context.dev takes over that maintenance curve at scale through one managed endpoint. The benefit is engineering time returned to your product instead of chasing detection updates.