Performance decrease with multiple contexts

[curvah]

Hi guys, when running N (from my tests 4 is enough to replicate) threads using a single shared Browser instance with one BrowserContext per thread, the turnstile challenge take significantly longer to resolve (or stall indefinitely) compared to spawning a dedicated Browser instance per task.

This is how I was creating the browser and the context (pretty straightforward):

browser = await launch_async(
        headless=False,
        geoip=False,
        humanize=True,
)
context = await browser.new_context(proxy={"server": "...", "username": "...", "password": "..."})

I tested the same script but creating one browser per task instead of using contexts and the results where as expected, each task managed to solve the challenge without any problem, but I had to use geoip=True (that I can't when using contexts).

Using VNC to see why its taking much to solve seems like that cloudflare is detecting something or something is not going as it should be (the "Stuck?" warning is a sign that is taking too much to load the challenge):

I am running this on docker with xvfb and the cloakbrowser version is 146.0.7680.177.3

Is this expected behavior, or does it point to a bug in context isolation?
Im always open to test more if needed, thanks in advance for any help :)

[Cloak-HQ]

Thanks for the report.

We tested your scenario on our end and found the root cause isn't context isolation — it's a geoip limitation you already noticed.

What's happening

timezone and locale are process-level binary flags, set once when the Browser launches. geoip=True only resolves them if the proxy is passed to launch_async() — not when the proxy is set on new_context(). We confirmed this:

• launch_async(geoip=True) + new_context(proxy=DE) → timezone=UTC, locale=en-US
• launch_async(geoip=True, proxy=DE) + new_context() → timezone=Europe/Berlin, locale=de-DE

So in your shared-Browser setup, every context runs with UTC + en-US regardless of each proxy's country. That geo mismatch is a strong signal for Turnstile's managed challenge → interactive mode → "Stuck?" stall. One Browser per task works because each launch can resolve geoip properly.

We were not able to reproduce the stall on the official Turnstile demo (demo.turnstile.workers.dev) — 4 concurrent contexts on a shared Browser solved in 3-5s each. So the concurrency itself is fine; the issue is the geo mismatch.

Workarounds

1. Keep one Browser per proxy (what you already found works).
2. Or shared Browser, but set timezone + locale explicitly at launch to match the country you intend to use — all contexts will share that tz/locale though, so only works if all your proxies are in one country.
3. You can also pass a single "anchor" proxy at launch with geoip=True and use per-context proxies, as long as all contexts match the launch proxy's country.

Let us know if this matches what you're seeing on your target site.

[curvah]

Thanks for the reply!

First of all, sorry for missing the target url used in the test, here it is: https://www.scrapingcourse.com/cloudflare-challenge

I'm worried that the source of the problem could be something else. I can assure that Cloakbrowser is able to pass the challenge when running 3 shared contexts (without any geoip/locale & timezone flags set) in a high amount of time (around 25s, sometimes more). Setting timezone & locale helps to solve them faster (around 14s), but seems like it doesn't solve the indefinite loop on "Stuck?" when increasing the number of concurrent shared contexts to 4 or 5.

I tested my script on the turnstile demo and I can confirm that it passes correctly even without geoip and with more than 6 tasks, so I think that it can be something regarding my target site.

[curvah]

Hi, just following up on this issue. I was wondering if you’ve had a chance to investigate it or if there are any plans to update it.
One new thing I've tried is to set the timezone and locale manually per context (as I noticed from the playwright documentation that is possible) but it ended in a challenge loop (I can imagine because cf can detect it somehow).
Happy to provide more details if needed!

[mvanhorn]

Submitted #230 with a one-time warning when geoip=True is set at launch but a later new_context() gets its own proxy. Docs + Python/JS parity. If the deeper investigation in this thread turns up a per-context resolution bug beyond geoip, that would be a separate change.