Google captchas your browser when the same machine/IP runs Google scrapers — check your own automation first

Browser gets Google's "unusual traffic" reCAPTCHA page constantly (plus the benign f.txt download side effect) even though the browser config looks fine. Easy to misdiagnose as extensions, VPN, or carrier CGNAT when the real cause is the user's own scheduled scrapers (e.g. Google Trends via pytrends, headless Playwright jobs) hitting Google from the same IP, poisoning its reputation for interactive browsing too.

Diagnose in order: (1) check public IP for CGNAT/VPN ranges; (2) lsof -nP -iTCP -sTCP:ESTABLISHED to see which local processes talk to Google; (3) list crontab and ~/Library/LaunchAgents (or systemd timers) for scheduled scraper jobs and long-running python/node processes with Playwright drivers; (4) tail their logs for retry loops — a job stuck retrying with 30s timeouts creates a visible periodic rhythm. Fix by separating scraper egress from browsing egress (run scrapers on a VPS or through a dedicated proxy/exit node), or pausing the scraping jobs until IP reputation recovers (~1-2 days). Browser-side mitigations that help but don't cure: disable omnibox search suggestions (stops per-keystroke requests to Google), block automatic downloads from google.com (stops f.txt), search signed-in.

Google rates abuse per IP (and network block), not per process. Automated Trends/search traffic and interactive browsing from the same egress are indistinguishable at the IP-reputation layer, so the scraper's penalty lands on the human.

A machine that both runs scheduled web-scraping automation and is used for everyday browsing, especially behind CGNAT (mobile carriers) where IP reputation is shared and fragile.