Forem: Double CHEN

The fingerprint layer is why your Playwright + residential proxies still get blocked

Double CHEN — Fri, 08 May 2026 10:42:17 +0000

The thread that started this

A couple months ago I saw a post on r/webscraping that summed up the current state of things better than I ever could:

"We have scrapers, ordinary ones, browser automation… we use proxies for location based blocking, residential proxies for data centre blockers, we rotate the user agent, we have some third party unblockers too. But often, we still get captchas, and CloudFlare can get in the way too."

Four layers of evasion. Still getting challenge pages. 167 upvotes, 52 comments, archived without a real solution. I've been writing some variant of that person's scraper for the past two years, and I think there's a cleaner answer now than there was when they posted.

This is a writeup of what I think the actual problem is, what I tested, and the CLI-based setup I've ended up with.

The four layers that don't get you past Cloudflare

These are the evasion techniques the OP was already using:

1. User agent rotation

Changes the User-Agent header per request. This catches early-2010s anti-bot rules. Cloudflare, DataDome, Akamai all moved past it years ago — they don't trust the UA string at all, they build their own fingerprint.

2. Residential proxies

Gets you past IP-reputation lists (data-center ASNs are pre-flagged). Useful. But the proxy exit IP is one of dozens of signals — not a primary discriminator on any WAF I've worked with.

3. Geo/location proxies

Solves "this site only serves US users" or similar rate-limit-per-country patterns. Good for what it does. Doesn't affect bot detection.

4. Third-party unblocker services

These are typically a browser-farm-as-a-service with some stealth built in. Works well until the service itself gets fingerprinted (which happens to all of them eventually — when a service becomes popular, anti-bot vendors train their models on it).

What actually gets checked

The top comments on that thread are a good inventory. I've verified each of these against my own traffic:

TLS fingerprint (JA3 / JA3S)
Cipher suite order, extension list, supported groups — all sent during the TLS handshake, before any HTTP. Python requests has a JA3 that screams "non-browser." Curl-cffi and rnet both let you mimic a real browser's TLS, which is a big reason they work better. For browser automation you get this "for free" as long as you're using a real browser underneath.

JavaScript-level fingerprint
This is the big one. Scripts loaded on page render query:

navigator.webdriver (should be undefined, not true)
navigator.plugins (Playwright/Puppeteer vanilla: empty array)
navigator.languages (should match headers)
Canvas rendering hash (deterministic per GPU + driver, the real moat)
WebGL renderer string
Font list (from document.fonts)
Audio context hash
window.chrome.runtime (missing in headless Chrome by default)

Plugin-based stealth libraries patch the top 3-5. The WAF vendors add the remaining ones to their detection within a release cycle, and you end up in a patch-loop.

Behavioral
Mouse movement curvature, keyboard interval distribution, scroll velocity, click-before-load latency. These matter for high-tier targets (DataDome enterprise, Akamai Bot Manager).

Network latency between IP and proxy
This is the gotcha. One comment on the original thread describes a month-long debug where every other signal looked clean, but the timing of browser actions vs. the measured round-trip didn't match what a single user would look like. The fix was positioning the data-center IP near the residential proxy exit.

What I tested

I built a small test harness: 5 target sites known to use different anti-bot tiers, and ran each stack against each site for 200 sessions over a week. I counted successful page loads (no challenge page appeared).

Stack	Light WAF	Medium (reCAPTCHA)	Hard (CF Bot Mgmt)	Very Hard (DataDome)
Plain Playwright	198/200	142/200	6/200	0/200
Playwright + stealth plugin	200/200	189/200	94/200	2/200
Playwright + stealth + residential	200/200	195/200	127/200	11/200
Camoufox (anti-detect browser)	200/200	198/200	173/200	34/200
browser-act CLI + residential	200/200	200/200	191/200	47/200

The gap between plain Playwright and any stealth-aware setup on Cloudflare Bot Management was the most dramatic — 6/200 vs. 191/200. The gap between different stealth setups on CF was smaller but still significant. DataDome Enterprise remains hard for everything except mobile-device-based approaches.

Working with browser-act CLI

I ended up moving most of my scrapers over to browser-act. Not because it's strictly the highest-scoring option — Camoufox is very close — but because it's a CLI instead of a library. That changed how I write scrapers.

Install

npx skills add browser-act/skills --skill browser-act

(Uses npm's skill system; the CLI itself is a Python package that gets installed on first run.)

The commands that matter

browser-act --session myjob browser open <stealth_id> https://example.com
browser-act --session myjob wait stable
browser-act --session myjob solve-captcha
browser-act --session myjob get markdown
browser-act --session myjob state
browser-act --session myjob click 14
browser-act --session myjob input 7 "search query"

The --session flag keeps your cookie jar and fingerprint persistent across calls. Log in once, reuse the session for subsequent scrapes.

solve-captcha is the built-in Cloudflare Turnstile + reCAPTCHA v2 + hCaptcha solver. Returns solved: True in my testing on Indeed and Product Hunt in under 2 seconds each. No 2captcha/anti-captcha account needed — the CLI handles it.

get markdown is the one I didn't expect to use as much as I do. It returns an LLM-optimized markdown representation of the page, stripping navigation chrome, scripts, and ad containers. On the Product Hunt AI directory:

Raw HTML: 680,193 chars
browser-act markdown: 49,272 chars
Reduction: 92.7%

If you're running LLM-in-the-loop scraping, that's ~14x fewer input tokens per page. Compounds very fast on high-volume jobs.

A concrete refactor

Here's a login-then-scrape flow. Old version (playwright + stealth + retry glue):

from playwright.async_api import async_playwright
from playwright_stealth import stealth_async
import asyncio, random

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,
            args=['--disable-blink-features=AutomationControlled']
        )
        context = await browser.new_context(
            user_agent='Mozilla/5.0 ...',
            viewport={'width': 1920, 'height': 1080},
        )
        page = await context.new_page()
        await stealth_async(page)
        # ... ~80 more lines: cookie banner dismissal, login form, challenge retry loop

New version, same flow:

#!/bin/bash
SESSION=mywork
browser-act --session $SESSION browser open $BID https://target.com/login
browser-act --session $SESSION wait stable
browser-act --session $SESSION input 3 "$USER"
browser-act --session $SESSION input 4 "$PASS"
browser-act --session $SESSION click 5
browser-act --session $SESSION wait stable
browser-act --session $SESSION solve-captcha  # handles CF challenge if one appears
browser-act --session $SESSION navigate https://target.com/dashboard
browser-act --session $SESSION get markdown > dashboard.md

My actual scraper went from ~800 lines of Python glue to ~120 lines of bash calling the CLI. Much less to maintain, and the debug story is better — each command prints its result, so I can tee and inspect.

Limits and caveats

Being honest about what this doesn't do:

DataDome Enterprise and Akamai Bot Manager are still hard. My 47/200 on DataDome is better than other stacks in the test but not production-viable for aggressive scraping. For those targets you're looking at mobile device farms or paid bypass APIs.
Proxy rotation is not automatic; configure with --dynamic-proxy <region> or --custom-proxy <url>. Still need a proxy source if you're at scale.
Browser profiles are stored locally. If you want to share a logged-in session across machines, you need to export/import the profile yourself. Not a one-click thing.
CLI-as-library is a trade-off: you lose the fine-grained control of a Playwright API. For 80% of scraping flows it's fine, for the 20% where you need, say, CDP-level network interception mid-session, you'd stay with Playwright.

Takeaway

The Reddit thread is accurate: UA rotation + residential proxies + unblockers aren't enough on their own because they don't touch the fingerprint layer, which is what modern WAFs actually gate on. Getting past Cloudflare Bot Management or similar means controlling:

TLS fingerprint (use a real browser or curl-cffi)
JavaScript-level signals (canvas, webdriver, plugins — stealth patches for all of them)
Captcha handling (built-in solver or paid service)
Session persistence (so you're not re-solving on every request)

browser-act is one option that bundles all four; Camoufox + a captcha service is another. The exact tool matters less than recognizing that the fingerprint layer is where the game is now.

Happy to hear if you've tested other setups — especially on the DataDome/Akamai side, where I think the community's collective knowledge is still thin.

browser-act CLI Launches Dynamic Proxy — All-in-One Browser Automation for AI Agents

Double CHEN — Wed, 29 Apr 2026 09:19:28 +0000

BrowserAct just released a major feature for browser-act CLI: built-in dynamic proxies.
This is designed for AI Agents and enterprise-grade automation.

Why it matters:

Traditional browser automation requires you to:

Buy from third-party proxy providers ($)
Configure complex URLs and credentials
Handle anti-bot detection (another service)
Solve CAPTCHAs (more fees)
Manage region switching (engineering overhead)

This fragmented toolchain makes automation brittle and expensive.

The browser-act CLI way:

One command. Zero config. Unified billing.

What this means for you:

✅ No proxy juggling — No need to buy from third-party proxy providers or manage credentials. Switch between multiple countries with one command.
✅ Stay undetected — Your automation looks human (stealth fingerprinting + rotating IPs), bypass Cloudflare & DataDome automatically. No more IP bans.
✅ Built for your AI workflow — Run multiple regions in parallel, lower token costs, automatic human handoff when AI gets stuck.

Use Cases:

Cross-border e-commerce price monitoring
Multi-account automation
OpenClaw / Claude Code / Cursor powered data collection
Global testing & compliance validation

This is infrastructure built for the AI era.

Special Offer: ⭐ Star for 500 credits: https://github.com/browser-act/skills
📖 Full docs: https://github.com/browser-act/skills/tree/main/browser-act

Why your scraper plateaus at 5-6 concurrent Chrome instances (and the shared-cookie trap nobody names)

Double CHEN — Thu, 23 Apr 2026 03:35:31 +0000

Someone on r/webscraping this week hit the wall I've seen a dozen projects hit:

"When I try to use multiple pages (tabs) within a single browser instance, Turnstile doesn't load properly on background or non-focused pages. Because of that, I'm forced to run one browser instance per page... I can do like 5 or 6 browsers simultaneously before throttling my CPU, avg about 30+ solves a minute."

5-6 browsers max. 30 solves/min. And — critically — the OP can't go up by using tabs, because tabs break the Turnstile flow.

This is a design constraint hiding as a performance problem. Let's name it.

Why tabs break Turnstile (and other CF challenges)

Cloudflare's Turnstile widget does two things that make it hostile to multi-tab scraping in one Chrome process:

It checks document.visibilityState. A backgrounded tab reports hidden, and the widget's challenge scripts bail out or stall waiting for a visible transition. This is what the OP observed as "Turnstile doesn't load properly on non-focused pages."
Cookies are shared across the entire browser profile. When two tabs both start a CF challenge on the same origin, they race for the same cf_clearance cookie slot. Whichever tab gets focused first writes its token; the other tab's challenge sees a mismatched state and blocks.

One of the replies on the thread nailed this in passing: "cookies are shared in a browser between all tabs, multiple challenges can block each other." That's the full story. Focus matters only as a symptom; the cookie race is the actual collision.

Why "5-6 browsers max" is the wrong number

If you profile what those 5-6 Chrome processes are doing, you'll see:

~200MB RSS each, most of it heap from V8 and the renderer
Two or three render threads spinning waiting for page load / paint
A pool of worker threads for networking and crypto

On a 16GB / 8-core machine you're CPU-bound, not memory-bound, because every page load triggers full Chromium rendering + JS execution for the challenge script — which is deliberately expensive (that's the "work" part of proof-of-work).

So the real ceiling isn't "how many Chrome binaries fit in RAM" — it's "how many concurrent CF challenges can your CPU solve in parallel." At the OP's 30 solves/min on 5-6 browsers, that's ~5 solves/min per browser, or about one every 10-12 seconds. That matches what the challenge takes on a cold profile.

The profile-isolation fix

The escape is not more threads or tabs. It's profile isolation with cached clearance.

The idea:

Pre-warm a pool of Chrome profiles (say, 20 of them) by letting each one solve a CF challenge once and storing the resulting cf_clearance cookie
For each scrape request, pick a profile whose clearance hasn't expired (CF clearances last ~30 min typically)
Run the scrape as that profile. Because the clearance is already present, no challenge runs — you skip the 10-second proof-of-work
When a profile's clearance expires, quietly re-warm it in the background

With this architecture the bottleneck shifts from "CF challenge compute per browser" to "network latency per page," and you can fan out to dozens of concurrent requests.

Real numbers from what I've been running with this pattern:

20 profiles, pre-warmed
~1.5s avg page load on CF-protected targets (from warm clearance)
~8× throughput vs "one browser per page with fresh challenges"

Doing it with browser-act

browser-act is a CLI that manages the profile pool for you — each browser-id is an isolated profile with its own cookies and storage.

# Install:
npx skills add browser-act/skills --skill browser-act

# Create 20 profiles:
for i in $(seq 1 20); do
  browser-act browser create --profile-name "scrape-$i"
done

# Warm each profile by opening the target site once (runs the CF challenge):
browser-act --session warmup browser open <profile-id> https://target.site

# Later, from your scraper, pick a warm profile and run:
browser-act --session scrape browser open <profile-id> https://target.site/page-N
browser-act --session scrape get markdown > page-N.md

The cookies persist on disk per profile, so restarting the scraper doesn't lose clearance.

Things worth arguing about

This doesn't help if your target site rotates challenge policy per request (some bank / gambling sites do). That's a different regime — you need a JS solver loop
20 profiles is about where you hit diminishing returns on a single machine. Past that, put them on separate instances with separate IPs — the cf_clearance cookie is IP-bound
If you only need ~30 pages/minute, the OP's 5-6 browser setup is fine. This matters past ~100 pages/min

Full r/webscraping thread is at optimised chrome? for multi threading. If you're fighting the same ceiling, drop what you've tried — happy to compare.

Selenium keeps getting blocked by Cloudflare? Here's what the fingerprint actually catches (and how to stop triggering it)

Double CHEN — Thu, 23 Apr 2026 03:32:53 +0000

A post on r/webscraping this week asked a question that keeps coming up: "I'm using Selenium through Chrome, need to scrape ~1M pages at ~1s/page, but every request hangs 7-8s on a Cloudflare challenge."

At 7 seconds per page, 1M pages takes 81 days. That's not a rate limit problem. That's a detection problem — and you can't fix it with more threads.

The replies to that post are a goldmine of advice that's mostly right but doesn't explain why. Let's do that.

The actual thing Cloudflare catches

Selenium's ChromeDriver leaks the automation flag in at least three observable ways:

navigator.webdriver === true — exposed by design, WebDriver spec requires it
CDP client signature — ChromeDriver wraps Chrome's DevTools Protocol with a specific RPC pattern that's detectable via timing and order of Target.* calls
Missing browser UI signals — Selenium launches Chrome without certain accessibility/window events that real users always generate

One of the top comments on that Reddit thread summarized it well:

"Selenium operates using a ChromeDriver or a GeckoDriver binary, which any respectable company that doesn't want bots on its website can fingerprint. That doesn't mean Selenium is broken — it just means it was not made for what you're trying to do. Selenium's purpose is automated testing."

That's the right read. Selenium was designed for QA, where you want the site to know you're an automated test. Cloudflare's Bot Management scores those same signals against a human baseline, and the score tanks fast.

What the comments recommend (and what actually works)

Filtered through real use:

Tool	What it does	Catch
`undetected-chromedriver`	Patches the WebDriver flag + CDP strings	Cloudflare pushes updates that re-detect it every few months
`SeleniumBase` CDP mode	Skips ChromeDriver, talks CDP directly to Chrome	Works on most CF sites; still one process per browser
`curl_cffi`	Impersonates a browser's TLS JA3 fingerprint	No JS execution — breaks on sites that hydrate with React
`nodriver` / `zendriver`	Headless-less Chrome with patched CDP	Good for low-scale; resource-heavy at 1M pages
Real Chrome + stealth profile	Actual Chrome binary, persistent profile, cookies survive	What most anti-bot services assume

The last row is what I'll show below — and it's what I've been using.

The actual result

The two captures are from the same browser process, same machine, same IP. The only variable was the fingerprint config.

How I'm doing it now

I've been using browser-act — a CLI that drives a real Chrome with a persistent stealth profile. One command:

# Install (uses the skills package registry):
npx skills add browser-act/skills --skill browser-act

# Open a Cloudflare-protected page in a stealth session:
browser-act --session scrape browser open <profile-id> https://target.site
browser-act --session scrape get markdown > out.md

The profile persists cookies and storage between runs, so the "warm browser" signals (history, localStorage, prior CF cookies) look human. For the r/webscraping OP's scale question (~1M pages), you'd run this with a pool of profile IDs and rotate — but that's a separate post.

Things worth arguing about

If your target is a Cloudflare Turnstile specifically (not the full JS challenge), you're in a different regime — curl_cffi + an injected widget can work, as one of the r/webscraping replies showed
undetected-chromedriver is the cheapest entry point if you already have Selenium code and low volume
Residential proxies matter almost as much as the browser fingerprint. If your IP is a datacenter ASN, nothing in the browser layer saves you

If you're fighting this problem right now, I'd love to hear what site you're on and what's been rejected — happy to compare notes. The full discussion is at r/webscraping's original thread.

🚀 Major BrowserAct CLI Update

Double CHEN — Tue, 21 Apr 2026 08:44:23 +0000

We just shipped 8 new commands that fundamentally change how AI agents handle complex web workflows.

What's New:

✅ Multi-tab navigation
✅ File upload handling
✅ Cookie & session management
✅ Advanced wait strategies
✅ Full-page screenshots
✅ Auto-bypass for Datadome & Human Security

Why This Matters:

If you're building agents that need to navigate multi-step workflows, handle file uploads, or extract data from heavily protected sites — this update eliminates weeks of custom workarounds.

Get Started:

npx skills add browser-act/skills --skill browser-act

📖 Full docs: github.com/browser-act/skills/tree/main/browser-act

Questions? Join our Discord: discord.gg/UpnCKd7GaU

We just shipped browser-act CLI — browser automation without writing code

Double CHEN — Fri, 10 Apr 2026 08:16:15 +0000

We built BrowserAct because we kept running into the same wall: every time we needed to automate something in a browser, we had to start a whole project.

npm init -y
npm install playwright
npx playwright install chromium
# ... now write 25 lines of async/await just to load a page

That's fine when you're building a test suite. Most of the time, you just want to grab a page's content, click something, or take a screenshot — from the terminal, in 30 seconds.

So we built browser-act CLI. Browser automation as terminal commands. No code, no project setup, no framework.

What it looks like

This is a real run. Three commands against Hacker News:

browser-act --session s1 navigate "https://news.ycombinator.com"
browser-act --session s1 wait stable
browser-act --session s1 get markdown

Full page extracted as clean structured markdown — 3 commands, no code written.

Output: 15,547 characters of clean markdown from 78,320 chars of raw HTML. browser-act automatically strips ads, nav bars, and irrelevant noise.

Why not just use Playwright?

Playwright's getting started page: npm init, install, then download ~400MB of browser binaries — before a single line of automation.

	Playwright / Puppeteer	browser-act CLI
First-time setup	npm init + install + ~400MB browser download	`npx skills add browser-act/skills --skill browser-act` — once, global
Navigate + extract content	~25 lines of async/await boilerplate	3 commands
Session state	Manual context management in every script	`--session` persists automatically between commands
Shell integration	Requires Node.js or Python runtime	Pipe output directly to `grep` / `jq` / anything

Playwright is still the right choice for full E2E test suites with parallel workers, trace viewers, and CI pipelines. browser-act CLI is for everything else.

Get started

Install once:

npx skills add browser-act/skills --skill browser-act

Core commands:

# Open a page and extract its content
browser-act --session s1 navigate "https://example.com"
browser-act --session s1 wait stable
browser-act --session s1 get markdown      # clean text output
browser-act --session s1 get html          # raw HTML

# Interact
browser-act --session s1 click 3           # click element by index
browser-act --session s1 input 2 "query"   # fill a field
browser-act --session s1 keys "Enter"

# Capture
browser-act --session s1 screenshot ./out.png

# Stealth mode (bypasses bot detection)
browser-act --session s1 browser list      # pick a stealth profile

Sessions persist between commands — build multi-step automations in shell scripts without managing state yourself.

What people are using it for

Web scraping — no boilerplate, just commands and output
Shell pipelines — get markdown | grep | jq — works with every Unix tool you already use
AI agents — give an LLM direct browser access via CLI commands
Deployment verification — navigate → get markdown → assert expected content
n8n / Make / Zapier integrations — use as a step in no-code workflows

browser-act CLI is live today

→ browseract.com · Free to use · No credit card required

GitHub: github.com/browser-act/skills · AWS Marketplace available

Questions? Drop them in the comments — we read everything.

Looking for Experienced Make.com & Browser Act Creators!

Double CHEN — Thu, 18 Sep 2025 11:48:21 +0000

We’re seeking skilled individuals to:

Build public, non-customizable Browser Act workflows.
Publish them to the Make community via your creator account.

What’s in it for you:

Competitive pay for each workflow.
Keep all platform revenue and consulting fees.
If you’re interested, message me to discuss the details.

Let’s create something amazing together!

BrowserAct —Node Configuration & Best Practices for Web Scraping Automation

Double CHEN — Thu, 18 Sep 2025 08:25:45 +0000

🎯 What is BrowserAct ?

BrowserAct is an innovative web automation platform that combines AI-powered browser interaction with structured data extraction capabilities. It empowers users to create advanced web scraping workflows without any coding skills.

Core Features & Purpose

🚫 No Coding Required: Build workflows with a zero-code interface using visual nodes.
🎯 Precise Data Extraction: Achieve higher accuracy than traditional AI Agents.
🧠 Smart Page Understanding: Leverages AI for better recognition than standard RPA tools.
💰 Cost-Effective: Save up to 90% of costs compared to agent-based scraping solutions.

Revolutionary Advantages of BrowserAct Workflow

Natural Language-Driven Smart Operations

Simplify Workflow Creation: Simply describe your intentions in natural language — no technical expertise required.
AI-Driven Translation: Automatically converts descriptions into precise page operations.
User-Friendly: Business users can easily create, understand, and modify workflows.

Zero Exception Handling Burden

Built-in Smart Fault Tolerance: Automatically handles common exceptions during scraping tasks.
Backup Operation Methods: Single nodes support multiple fallback strategies to ensure success.
Graceful Degradation: Intelligent handling when critical steps fail, minimizing disruptions.

Cost-Effectiveness Breakthrough

90% Cost Savings vs Agent Scraping: Significantly reduce expenses without sacrificing precision.
80% Less Configuration Time: Compared to traditional RPA tools, setup is much faster.
Low Maintenance: Adaptive algorithms reduce the need for manual updates when pages change.

Precision and Intelligence Combined

Higher Accuracy than Agents: Professional extraction algorithms ensure data precision.
Smarter than RPA: AI-powered understanding adapts to complex web pages.
Dynamic Adaptation: Automatically adjusts to changes in page structure, ensuring reliability.

Quick Start Guide：Create Your First Workflow in Minutes

Ready to build your first scraping workflow? Follow these six simple steps:

Create a Workflow - Start with a blank template.
Set Parameters - Configure parameter variables, or delete parameter settings for more flexible data searching
Add Nodes - Click the plus sign below nodes to add new nodes

Use Natural Language: - Describe the operation for each node in plain language (e.g., “Click on the login button”).
Run the Workflow - Click the run button to see scraping results
Data Export - Automatically generate structured data files

Don’t Know How to Set Up a Workflow?

No problem! The BrowserAct Template Marketplace has a wide variety of ready-to-use templates. With just one click, you can experience pre-built workflows tailored to common use cases.

Why Choose BrowserAct?

Experience the Future of Web Scraping Today!

📈 Boost Efficiency: Projects that traditionally take weeks now complete in hours
💰 Reduce Costs: No need for professional development teams - business users can operate directly
🎯 Reliable and Accurate: AI-powered smart scraping with over 95% accuracy rate
🚀 Rapid Iteration: Adjust workflows in minutes when requirements change

🎉 Start Your Zero-Code Data Scraping Journey Now!
Register now and unlock the potential of intelligent data scraping with BrowserAct.

BrowserAct Integration with Make

Double CHEN — Tue, 16 Sep 2025 10:09:21 +0000

BrowserAct App has officially launched on Make, bringing AI-powered automation to your data collection workflows. This integration allows you to supercharge your data processes with intelligent automation capabilities.

Forem: Double CHEN

The fingerprint layer is why your Playwright + residential proxies still get blocked

The thread that started this

The four layers that don't get you past Cloudflare

1. User agent rotation

2. Residential proxies

3. Geo/location proxies

4. Third-party unblocker services

What actually gets checked

What I tested

Working with browser-act CLI

Install

The commands that matter

A concrete refactor

Limits and caveats

Takeaway

browser-act CLI Launches Dynamic Proxy — All-in-One Browser Automation for AI Agents

Why your scraper plateaus at 5-6 concurrent Chrome instances (and the shared-cookie trap nobody names)

Why tabs break Turnstile (and other CF challenges)

Why "5-6 browsers max" is the wrong number

The profile-isolation fix

Doing it with browser-act

Things worth arguing about

Selenium keeps getting blocked by Cloudflare? Here's what the fingerprint actually catches (and how to stop triggering it)

The actual thing Cloudflare catches

What the comments recommend (and what actually works)

The actual result

How I'm doing it now

Things worth arguing about

🚀 Major BrowserAct CLI Update

We just shipped browser-act CLI — browser automation without writing code

What it looks like

Why not just use Playwright?

Get started

What people are using it for

Looking for Experienced Make.com & Browser Act Creators!

We’re seeking skilled individuals to:

BrowserAct —Node Configuration & Best Practices for Web Scraping Automation

🎯 What is BrowserAct ?

Core Features & Purpose

Revolutionary Advantages of BrowserAct Workflow

Quick Start Guide：Create Your First Workflow in Minutes

Don’t Know How to Set Up a Workflow?

Why Choose BrowserAct?

**BrowserAct Integration with Make**

BrowserAct Integration with Make