Skip to main content
Anchor Browser provides built-in stealth capabilities that help avoid detection by anti-bot systems and website fingerprinting. These features enable automated browsing that mimics human behavior and bypasses common detection mechanisms. Extra Stealth mode is available on the Growth plan.

What is Extra Stealth Mode?

Extra Stealth Mode leverages a specialized Chrome browser environment that provides:
  • 🔒 Advanced Anti-Detection - Bypass sophisticated bot detection systems and CAPTCHAs
  • 🛡️ Automation Consistency - Maintain consistent access without getting blocked
  • 👤 Human-Like Behavior - Mimic real user patterns to avoid suspicion
Alternative Cloudflare-verified access to webpages is available through our Cloudflare Web Bot Auth Integration.

Quick start - Enable stealth features

1

Create a session with extra stealth enabled

Create a browser session with extra stealth features enabled using the SDK:
Extra stealth mode requires proxy configuration to be active. If proxy is disabled, extra stealth will be automatically disabled by the system.Read more about Proxy Configuration
2

Use the session for automated browsing

Once your stealth session is created, you can use it for automated browsing that bypasses common detection mechanisms:

Using stealth with tasks

Save stealth settings on the task via task_default_browser_configuration — a one-time setup. Include browser.extra_stealth and an active session.proxy (required):
If you pass a session_id to /run, that session’s config is used instead. See Run a Task.

Usage with Profiles

Use stealth mode with saved browser profiles for persistent authenticated sessions:

Enabling Console Logs

When extra stealth mode is enabled, page.on('console') events are disabled by default to prevent detection. If you need to capture console output, you must explicitly enable it.
To receive console log events while using extra stealth, enable console_logs in your session configuration:

Catching Captcha Events

When using stealth mode with captcha solving enabled, you can listen to captcha lifecycle events via CDP (Chrome DevTools Protocol). This allows you to track when captchas are detected, solved, or failed.

Event Types

Session warm-up

Some sites show a login or sign-up wall to a browser they have never seen, even with stealth on: they check whether this browser has already run their own scripts once, on the IP it is using now. Turn on browser.warm_up and the session loads the site’s homepage once before it is handed to you, so your first navigation arrives with a jar those checks accept. On a warmed session, a direct navigation to that site also carries a search-engine referer; see Entering the site below. LinkedIn is the site covered today.
A warmed session needs both blockers off: browser.adblock.active: false and browser.popup_blocker.active: false. They stop the third-party analytics scripts these sites use to recognise a returning browser, so a warm-up under a blocker leaves no trace; the API rejects a warm_up request that leaves either one on.
The warm-up runs before the create-session call returns and adds about ten seconds to session creation; that time counts toward the session’s duration. It loads the page in the session’s first tab, which is left blank afterwards.
Entering the site. Some sites, LinkedIn among them, show a public page to a visitor arriving from a search result and wall the same browser on a direct navigation. On a warmed session the browser handles this for you: a direct navigation to the warm-up’s site carries a search referer, whether it comes from page.goto(profileUrl), the agent, or a URL typed into the address bar in the live view. Landing still depends on the reputation of the exit IP the session was given, and a new session gets a new exit.
The warm-up also makes one request to ipinfo.io through the session’s exit to record which IP the session used; it counts as session traffic like the rest of the warm-up.