Sudden CAPTCHA spike on Google SERP with default settings (free macOS binary, Chromium 145) — regression or IP-reputation / Google-side?

[mfcnsz]

Summary

Using CloakBrowser with default settings to fetch Google SERP results, my CAPTCHA
("sorry"/unusual-traffic interstitial) rate jumped from a historical ~2–5% to:

• Residential proxies: >70% CAPTCHA on fresh sessions
• Mobile proxies: ~40% CAPTCHA on fresh sessions

I changed nothing on my side — same code, same proxy providers, same launch
options. A few days ago the exact same setup ran essentially flawlessly; now a brand-new
session gets walled almost immediately. I'd appreciate guidance on whether this is a
CloakBrowser-side regression (i.e. should I buy/switch to the Pro binary), or a
Google/proxy-reputation–side change.

Environment

Item	Value
OS	macOS 26.1 (build 25B78), Apple Silicon / arm64
CloakBrowser wrapper	0.4.3 (pip)
Bundled Chromium (free, darwin-arm64)	145.0.7632.109.2 (from config.py CHROMIUM_VERSIONS)
License	Free (no license_key / CLOAKBROWSER_LICENSE_KEY set) → running the free v145 macOS binary
Playwright	1.58.0
Launch config	Defaults (headless, no custom fingerprint flags beyond defaults)
Use case	Google SERP scraping (google.com/search), one fresh context per request
Proxies	Reputable residential + mobile pools (rotating)

I note from the package METADATA that the green test results are "Last tested: Jun 2026
(Chromium 148)" against the Pro binary, and that the free binary "goes stale within
weeks as detection evolves." My macOS free binary is Chromium 145, so I want to
understand whether I'm simply on a binary that detection has caught up with.

What changed / timeline

• Onset: ~2 days ago, abrupt (not a gradual drift).
• No CloakBrowser upgrade, no code change, no proxy provider change on my side coincided
  with the onset.

Isolation tests I ran (to separate CloakBrowser vs Google/proxy)

To avoid the "something changed on your side" dead end, I tried to isolate the layer:

1. Same binary, only Playwright driver version changed (A/B):

   • Playwright 1.60.0 (Chromium 148 driver): SERP → CAPTCHA
   • Playwright 1.58.0 (Chromium 145/146 driver): SERP → clean
   • Same proxy, same machine, same target. Pinning to 1.58.0 measurably helped, which
     suggests at least part of the signal is browser/driver-fingerprint related, not
     purely IP reputation.

2. Browserless control (plain HTTP through the same proxy pool):

   • Issuing a plain HTTP GET to Google through the same residential IP pool (no browser,
     no CloakBrowser) returned a block/"sorry" response on roughly 27–40% of TR exit
     IPs at the very first request.
   • This indicates a real IP-reputation / Google-side component as well.

Interpretation I can't resolve on my own: the browser CAPTCHA rate (>70%) is far higher
than the browserless block rate (27–40%) on the same IPs, which implies an additional
browser-detectable signal on top of IP reputation — i.e. the fresh-session browser
fingerprint is now being flagged where it wasn't a few days ago.

Questions

1. Is the free macOS Chromium 145 binary now known to be detected on Google
   specifically (a stale-binary regression), and is Pro (Chromium 148) expected to
   restore the previous low CAPTCHA rate for Google SERP?
2. Are there recommended default-deviating settings for Google SERP at scale (persistent
   profile / launch_persistent_context, geoip, timezone/locale alignment to the proxy
   exit, etc.) that the free binary needs but Pro handles automatically?
3. Is there anything in the recent Google detection wave (May–Jun 2026) that you've already
   characterized and patched in 148 but not in 145/146?

I'm happy to run any controlled A/B you suggest (e.g. specific flags, a Pro trial key, or a
nodriver/stock-Chromium comparison on the identical IP pool) and report exact numbers.
Thanks for the great tool.