[Bug]: 100% CAPTCHA/Bot Detection Rate on Google SERP despite Mobile Proxies (Free Version)

[zekiyetarhan17-code]

Hello team,

We are currently running a high-concurrency SERP telemetry worker pool (our Harvester module built on Golang) connected to CloakBrowser via Playwright. Over the last few days, we have experienced a complete halt in our scraping pipeline. Every single Google SERP iteration is immediately flagged by bot detection (CAPTCHA), making it impossible to complete any workflow.

We are utilizing high-quality mobile proxies with frequent IP rotation, which previously worked flawlessly. It appears that the recent core and anti-spam updates from Google (late June 2026) have compromised the stealth capabilities of the current Free build.

Environment:

• CloakBrowser Version: Free build (Chromium v146)
• Automation Framework: Playwright (driven by Go worker pools)
• Proxy Setup: High-trust Mobile Proxies (residential IP range) with geoip=True enabled.
• OS/Architecture: [Sunucu işletim sistemini buraya yaz, örn: Ubuntu 24.04 LTS]

Steps to Reproduce:

1. Launch the CloakBrowser free binary using Playwright.
2. Pass a clean Mobile Proxy via launch arguments along with humanize=True and headless=False.
3. Navigate to Google SERP and perform a standard query search.
4. Immediate CAPTCHA or "Unusual traffic" block occurs, blocking any further rendering or DOM interaction.

Observations:

• IP reputation is not the issue, as the same mobile proxies function perfectly in a standard browser.
• We avoid any CDP-heavy commands like page.waitForTimeout() to prevent CDP leaks.
• Is there a scheduled stealth patch for the free (v146) binary to address the recent Google anti-bot updates, or are the necessary C++ fingerprint patches strictly mitigated in the v148 (Pro) build right now?

Any insights or ETA for an updated free release would be highly appreciated.

[Cloak-HQ]

Thanks for the detailed report.

To make sure we're debugging the browser and not the harness, could you share a minimal standalone Python repro that uses CloakBrowser directly (no Go worker pool in the loop)? Something we can run as-is:

import time
from cloakbrowser import launch

browser = launch(
    headless=False,
    humanize=True,
    proxy="http://user:pass@your-mobile-proxy:port",
    geoip=True,
)
page = browser.new_page()
page.goto("https://www.google.com")
page.type("textarea[name=q]", "your exact query", delay=120)
page.keyboard.press("Enter")
time.sleep(8)
page.screenshot(path="serp.png", full_page=True)

A few things that would help us reproduce the exact conditions:

1. Your OS — the issue template still has the placeholder ([Sunucu işletim sistemini buraya yaz...]), so we don't know what you're running on.
2. The exact query / SERP URL you hit the block on.
3. Proxy type — mobile vs residential, sticky vs rotating, and which country exit.
4. Whether the block is on the first navigation or only after N iterations in a session.

On the "is it the binary or Google's late-June update" question: it would actually be interesting to see how the v148 build handles the same flow, since it carries the newer fingerprint patches. If you're set up to try it that's a useful datapoint for us either way.

Let us know and we'll dig in.

— CloakHQ

[zekiyetarhan17-code]

Subject: Re: SERP block — standalone repro + environment details

Thanks — happy to give you everything to reproduce this cleanly. We stripped the Go worker pool out entirely; the block reproduces from a plain CloakBrowser script.

Environment

• OS: Windows 10 Pro 22H2 (build 10.0.19045), x64
• cloakbrowser: 0.4.3 (free tier)
• Chromium: 146.0.7680.177.5 (windows-x64, free binary)
• playwright: 1.58.0
• Python 3.x embedded runtime, app product version 3.0.0

Proxy

• Provider/brand: Oxylabs Residential (pr.oxylabs.io:7777)
• Type: rotating (new sessid per scan), HTTP, country exit = TR (aligned to gl=tr)
• Auth format we generate per scan: customer--cc-tr-sessid-:@pr.oxylabs.io:7777
• We can also force sticky (-sesstime-N) but the block happens on rotating and sticky alike.

Exact query / URL

• Query: nike spor ayakkabi
• URL: https://www.google.com/search?q=nike+spor+ayakkabi&hl=tr&gl=tr&num=10
• It is not query-specific — reproduces across queries, and with or without &num=10.

When does the block happen?

• On the very first navigation, before any interaction. The page lands directly on https://www.google.com/sorry/index?.... No N-iteration warm-up needed.

How we launch (exactly what our Ghost service does)

browser = launch(
    headless=True,                 # production default
    humanize=True,
    human_preset="careful",
    proxy="http://customer-...-cc-tr-sessid-...:...@pr.oxylabs.io:7777",
    timezone="Europe/Istanbul",
    locale="tr-TR",
    args=["--fingerprint=<stable-per-IP-seed>"],
)

Minimal standalone repro (runs as-is, no Go in the loop): attached serp_repro.py.

What we measured (this points away from the browser):
We ran a 4-fresh-IP sweep + controls on the same proxy/account:

Fresh TR exit IP	Google SERP
46.197.16.46	/sorry/ on first nav
88.236.167.239	/sorry/ on first nav
78.172.198.132	/sorry/ on first nav
151.250.60.111	OK — 9 organic results

• Same proxy + same browser → Bing and DuckDuckGo both load fine (full results), so the browser/proxy path is healthy.
• Fingerprint looks clean: navigator.webdriver=false, platform=Win32, tz=Europe/Istanbul (offset −180), lang/langs=tr-TR, UA Chrome/146, bot.sannysoft.com 22 passed / 0 failed.
• No WebRTC leak: 0 ICE candidates surfaced (HTTP-proxy → no STUN reflexive), so the real IP is not exposed.
• Removing the pre-seeded SOCS/CONSENT cookie made no difference (still /sorry/).

So on our side it correlates strongly with per-IP reputation on the Oxylabs residential pool (~3 of 4 fresh TR IPs are pre-flagged by Google and serve /sorry/ before any behavioral signal), rather than a fingerprint/stealth regression — the one clean IP returned full results through the identical code path.

Two things we'd love your read on:

1. v148 (Pro) datapoint: we're on the free tier (Chromium 146) and don't have a Pro license, so we can't currently run the v148 build. If you can share a trial/eval CLOAKBROWSER_LICENSE_KEY, we'll run the identical serp_repro.py against 148 and report the first-nav block rate on the same proxy IPs — happy to give you that comparison either way.
2. Minor 0.4.3 behavior change (FYI): launch(geoip=True) now hard-raises ImportError: geoip2 is required ... when the cloakbrowser[geoip] extra isn't installed. In 0.3.32 the kwarg was effectively a no-op when the extra was missing. Not a blocker for us (we pass explicit timezone/locale), but flagging it since the change is silent across the 0.3→0.4 upgrade.

Let us know what else would help. We can also send a HAR or the /sorry/ screenshot from the repro on request.

[Cloak-HQ]

Thanks, this is exactly the kind of repro that makes our side easy. We reproduced your flow on our end.

What we ran: same query (nike spor ayakkabi, hl=tr&gl=tr&num=10), headed, humanize=True, geoip=True, on Docker Linux. We tested both the free v146 binary and the v148 build, each across 9 fresh residential exit IPs spanning 5 countries.

Result: 0 /sorry/ blocks. Every run rendered the full SERP (9-10 organic results). Both binaries behaved identically.

That lines up with your own 4-IP sweep: the variable that flips /sorry/ on and off is the exit IP, not the browser. Google is gating these at IP reputation before any fingerprint or behavioral signal is evaluated, which is why Bing/DuckDuckGo load fine on the same proxy and why your one clean IP returned full results through the identical code path. Your diagnosis is correct.

On v146 vs v148: for the specific /sorry/ you're hitting, the block lands at IP reputation upstream of fingerprinting, so neither binary unblocks an already-flagged IP. The immediate lever there is proxy-pool quality. That said, running the newer build is still worth it over time: detection vendors increasingly treat older Chromium versions as suspect, so a v146 fingerprint ages into more scrutiny as the real-world browser population moves on. v148 keeps you aligned with the current version and carries the newer patches, which generally lifts success rates across sites even if it doesn't change this particular IP-level block.

For the proxy side, a few things that help with Google specifically:

• Test each exit IP before assigning it to a worker (a quick /search probe) and retire ones that return /sorry/.
• Prefer pools with lower Google-flag rates. Mobile (carrier-NAT) exits generally hold up better than residential for SERP at volume.
• Pace per-IP request rate rather than rotating harder. Aggressive rotation through a partially-flagged pool surfaces more flagged IPs, not fewer.

On the geoip FYI: we compared 0.3.32 and 0.4.3 directly and couldn't find a behavior change. The geoip2 import guard is identical in both versions, and it only triggers on the MaxMind lookup path (when timezone or locale is unset). Since you pass explicit timezone + locale, that path is bypassed entirely (it resolves the exit IP over HTTP, no geoip2 needed). If you have a traceback showing the ImportError on 0.4.3 with both tz and locale set, send it over and we'll dig in, but as-is we don't see a regression.

Let us know how the proxy-pool side goes, happy to keep helping.

— CloakHQ

[zekiyetarhan17-code]

Hello,

Thank you for getting back to me.

As I understand it, the biggest issue at the moment is the IP, so I should focus on resolving that first.

In that case, could you please recommend the proxy provider you are using? Unfortunately, I think the one I’m currently using is either not very good or its IP pool has been exhausted.

[BifrostCore]

After my testing, using our residential rotating proxies can successfully complete the scraping

[PriyeshPandey2000]

Hello,

Thank you for getting back to me.

As I understand it, the biggest issue at the moment is the IP, so I should focus on resolving that first.

In that case, could you please recommend the proxy provider you are using? Unfortunately, I think the one I’m currently using is either not very good or its IP pool has been exhausted.

I am doing something similar at my company right now , scraping Google SERPs at scale, although we're using a different browser.
I've tried both Oxylabs and Smartproxy (Decodo) proxies. I think a lot of Oxylabs' proxies are already burned. Even with their SERP API, they often fail to return paid ads.

We then bought a large batch of IPRoyal proxies. Initially, the results were pretty good, but after scraping at scale from the same locations for a while, the CAPTCHA rate gradually started increasing again.

I think this is probably common across all proxy providers since the same proxy pools are shared by other customers, who may be burning them or not using good anti-bot techniques. . Once my bandwidth exhausts I was thinking of trying this (haven't tried yet) but I think this can give better results as it is proxy aggregator of major providers so they themselves keep checking the quality and give the best performing proxies .
https://scrapeops.io/proxy-aggregator/

[markg85]

I have this issue too. I'm not running cloakbrowser on a datacenter. It runs locally in a docker container. My case is more of a "borderline risk score" where it's detected as bot sometimes and lets it through other times.

I did let an AI run analysis on it and there are surprising finding that could improve "cloak" to actually "cloak". The intent with this browser is to present it as a human and real visit and not hit bot detection! Here are the issues it identified:

 1. Locale ↔ IP mismatch (highest-impact, fixable) ⭐
 - Exit IP --REDACTED--
 - But the browser reports navigator.language = "en-US", languages = ["en-US"], and Accept-Language: en-US.
 - CloakBrowser process config: locale: null → Chrome defaulted to the bundled en-US build.
 - A real Dutch residential user on --REDACTED-- virtually never has an en-US-only browser. This single mismatch is a classic, high-weight automation signal and is the most likely repeated trigger.
 - (Timezone is fine: host TZ = Europe/Amsterdam (CEST +0200), which matches the IP geo — so timezone: null happens to be coherent here.)

 2. navigator.websocket getter appears patched
 - fp-collect reports webDriver: true with webDriverValue: false. The value reads false (sannysoft's basic WebDriver test passes), but the getter is detected as overridden/patched. Google-grade checks that
   inspect Object.getOwnPropertyDescriptor(Navigator.prototype,'webdriver').get will catch this.

 3. window.chrome.runtime is missing/broken
 - fp-collect: detailChrome.runtime → TypeError: Cannot read properties of undefined (reading 'constructor'); webstore also throws; connect/sendMessage undefined.
 - A genuine headed Chrome has a real populated window.chrome.runtime object. Its absence here is a known automated-Chrome tell (CloakBrowser/puppeteer weak spot).

 4. Broken-image dimensions 16x16
 - sannysoft's "Broken Image Dimensions" returned 16x16. Real Chrome reports 0x0 for a failed image; 16x16 is the historical headless signature. Either the instance is running a headless/new mode or images
   aren't loading normally — a yellow flag.

 5. What's actually consistent (not the cause)
 - UA Win64/x64 + navigator.platform = "Win32" + WebGL ANGLE (NVIDIA, GeForce RTX 3080, D3D11) → all coherently claim a Windows + NVIDIA machine. (The host is Linux, so this is a
   spoofed-but-internally-consistent fingerprint — good.)
 - Plugins length 5 (PDF viewers) — present, good (headless shows 0).
 - Permissions prompt, canvas hashes stable, no Selenium/Phantom/Sequentum markers.
 - Residential NL IP with good reputation (not a datacenter block — ip-api.com itself 403'd us, but ipwho.is confirmed --REDACTED-- consumer ISP).

Some of these issues are fixable on the tool side in the agent itself. Some are issues that need to be fixed in the docker container.