TL;DR
- Cloudflare, DataDome, Akamai, and HUMAN Security inspect TLS and HTTP/2 signatures, browser fingerprints, IP reputation, and session behavior.
- Raw headless browsers and basic browser proxy setups often expose automation flags, network signatures that do not match the claimed browser, software-rendered WebGL, and repetitive interaction patterns.
- Authorized agents should preserve cookies, storage, fingerprints, and IP identity within each session. A browser sandbox should also detect challenge pages instead of treating every 200 response as valid content.
- Anchorbrowser combines Anchor Chromium, humanized fingerprinting, session persistence, and Web-Bot-Auth. Verified identity gives supported sites a cryptographic reason to admit an agent, while humanized infrastructure handles authorized access where verification remains unavailable.
How bot detection actually works
Cloudflare, DataDome, Akamai, and PerimeterX evaluate each visit in layers. A request can accumulate risk signals before the page loads, while browser scripts run, and throughout the session. Passing one layer does not cancel inconsistencies found elsewhere.
TLS and HTTP/2 fingerprints provide the earliest signal. During the TLS handshake, the client exposes an ordered set of connection parameters that systems summarize as a JA3 or JA4 fingerprint. HTTP/2 adds signals such as frame settings and header ordering. Because these checks occur before the server reads ordinary HTTP headers, copying Chrome’s User-Agent string cannot disguise a request sent through the TLS stack used by Python requests or a basic Node client.
JavaScript fingerprinting tests whether the claimed browser matches the device behavior it exposes. Challenge scripts compare canvas and WebGL output with the reported operating system and graphics hardware. They can also inspect audio processing, installed fonts, browser plugins, timezone settings, and navigator properties such as webdriver. Headless Chromium may expose software rendering through a WebGL value such as Google SwiftShader. PerimeterX can also use WebAssembly execution speed to identify the underlying engine despite a spoofed User-Agent, according to technical analysis of its sensor.
Behavioral scoring continues after the initial page load. Bot defenses measure request cadence, navigation paths, scroll patterns, mouse movement, and click timing across a session. They also compare those actions with the IP reputation, cookies, and device fingerprint attached to the visit. DataDome can bind a clearance token to the TLS profile, HTTP/2 behavior, and IP, so replaying the cookie through a different browser proxy may invalidate the session. Akamai similarly evaluates browser telemetry when issuing cookies such as _abck, then keeps scoring later activity. Reported Akamai behavior includes empty fields or altered content when the session fails validation.
Bot detection often produces a silent failure instead of an obvious block. A server may return 200 OK with a challenge shell, redirected HTML, empty data, or substitute content. A naive scraper records the request as successful because it checks only the status code. Reliable automation must also validate expected page elements, response headers, body markers, and data completeness before accepting the result.
Bypassing Cloudflare
Use the following escalation only for sites where you have permission to automate access.
-
Detect Cloudflare challenges before parsing the response. Check for HTTP 403 or 503, error 1020, and text such as “checking your browser” or “Just a moment.” Search the response body for cf-chl-, cf-challenge, and “Ray ID.” Cloudflare sometimes returns a challenge page with HTTP 200, so status codes alone can record a false success.
-
Start with a client whose TLS and HTTP/2 fingerprint matches its claimed browser. Cloudflare evaluates JA3 or JA4 handshake details before reading the User-Agent header. Python requests, Node HTTP libraries, and raw browser proxies cannot imitate Chrome by changing headers alone.
-
Escalate JavaScript challenges and Turnstile to a hardened browser engine. The browser must execute Cloudflare’s scripts while presenting consistent values for navigator.webdriver, plugins, timezone, canvas, and WebGL properties. Generic headless browser settings and common stealth plugins often leave conflicting signals. Keep the browser sandbox open long enough to receive and retain Cloudflare clearance cookies.
-
Pin each browser session to a reputable IP with permission from its owner. A residential connection may face fewer reputation challenges than a cloud data center address, but frequent proxy rotation can invalidate the session. Reuse the same browser profile, cookies, local storage, and IP for returning visits. Add realistic pauses and interactions only when they reflect the agent’s actual task.
-
Prefer Web Bot Auth when the site accepts verified agents. The agent signs each request with its registered key, and Cloudflare verifies the signature against the operator’s public key directory. Sites configured to allow that verified identity can exempt the agent from Turnstile and JavaScript challenges. Anchorbrowser pairs Web Bot Auth with Anchor Chromium and persistent sessions for sites that still rely on conventional browser checks.
Bypassing DataDome
-
Detect DataDome challenges before processing the response. Check for 403 or 503 status codes, the x-datadome header, and page references to datadome or captcha-delivery.com. Some blocked requests return normal-looking HTML, so content validation prevents your agent from treating a challenge page as target data.
-
Use a browser-compatible network fingerprint. DataDome evaluates the TLS handshake and HTTP/2 behavior before page scripts run. A raw HTTP client can fail even when it copies Chrome headers. For authorized access with limited JavaScript, a browser-impersonating client may satisfy lower-friction checks.
-
Escalate active challenges to a hardened browser sandbox. DataDome can execute JavaScript that inspects canvas output, WebGL properties, timing, and automation indicators. A real Chromium engine gives those checks a coherent device profile that header spoofing cannot provide.
-
Keep the complete client shape stable for each session. DataDome can bind its token to the TLS and HTTP/2 fingerprints as well as the IP address. Keep the same browser profile, proxy endpoint, and cookies together until the session ends. Rotating the IP or changing the network stack while replaying the cookie can invalidate the token.
-
Preserve normal session behavior. Reuse authenticated state, apply conservative request rates, and avoid rapid proxy rotation. A residential proxy can provide ordinary consumer network reputation, but DataDome can still block an IP after aggressive activity.
-
Prefer verified access when the site supports it. DataDome’s Device Check reflects its move toward identifying trusted AI agents directly. Verified identity gives site owners a clearer basis for granting automation access than repeated fingerprint modification.
Bypassing Akamai
For authorized automation, Akamai requires a coherent browser session rather than a one-time challenge pass.
-
Use a real browser with engine-level fingerprint handling. Akamai compares JavaScript signals such as canvas, WebGL, navigator properties, and timing with the browser’s TLS and HTTP/2 behavior. JavaScript stealth plugins often redefine browser APIs, and Akamai can inspect .toString() output for evidence that native functions were replaced. A browser fork such as Anchor Chromium can apply fingerprint changes inside the engine, where page scripts cannot inspect ordinary JavaScript overrides.
-
Keep the browser identity and connection consistent. Hold the same browser profile, proxy endpoint, TLS signature, screen properties, and user agent for the full session. Rotating an IP while retaining the same cookies creates a mismatch. A residential proxy may improve IP reputation, but it cannot compensate for an inconsistent browser fingerprint.
-
Preserve Akamai’s cookie lifecycle. Akamai’s script collects browser and behavioral signals in a sensor_data payload. Successful validation can produce the primary _abck clearance cookie and supporting cookies such as ak_bmsc and bm_sv. Persist the complete browser sandbox so later requests retain cookies, storage, and navigation history. Do not treat cookie presence as proof of clearance because Akamai can issue a rejected _abck value.
-
Monitor content and behavior throughout the session. Akamai reportedly combines more than 100 signals into a confidence score ranging from 0 to 100. Repeated click timing, identical scrolling, abrupt navigation, or uniform delays can degrade the score after an initial pass. Use bounded timing variation and realistic navigation paths.
-
Detect silent rejection. Akamai may return 200 OK with empty fields, altered HTML, or redirected content. Validate expected page elements and response data instead of checking status codes alone. When a site offers an approved agent identity or automation API, use that route rather than repeatedly modifying fingerprints.
Bypassing PerimeterX (HUMAN Security)
-
Confirm PerimeterX before changing your browser configuration. Look for _pxvid, _px3, or _pxhd cookies, along with requests to collector-*.perimeterx.net or collector-*.px-cloud.net. PerimeterX uses an Enforcer to inspect tokens, a browser Sensor to collect signals, and a cloud Detector to score the session.
-
Run authorized automation in a persistent stealth browser. The Sensor checks canvas, WebGL, browser properties, and signs of JavaScript tampering. It can also use WebAssembly execution speed to identify the underlying browser engine despite a spoofed user agent. A hardened Chromium build provides a more consistent environment than scripts that patch navigator.webdriver.
-
Keep the visitor identity and network route together. The _pxvid cookie identifies the visitor, _pxhd represents the device, and _px3 carries the current risk token. Reusing the same browser profile, proxy address, and cookie jar reduces contradictions between those signals.
-
Treat behavior as part of the session. PerimeterX evaluates mouse movement, scrolling, click timing, and keystroke patterns. Its Press & Hold challenge records signed interaction telemetry while the user holds the control. Replaying headers or cookies cannot reproduce the associated behavioral record, according to descriptions of its behavioral checks.
-
Use hybrid handoff only for short, authorized jobs. A documented pattern lets a real browser complete verification and then passes its cookies to a lightweight HTTP client. The _px3 token expires quickly, with published estimates ranging from about 60 seconds to several minutes. PerimeterX can also request fresh Sensor data, so the hybrid approach requires the browser to remain available for renewal. For internal QA, request an approved access token or monitoring bypass from the site owner instead of automating the challenge.
CAPTCHA handling: avoidance first, solving last
CAPTCHA avoidance costs less and fails less often than solving every challenge. A stable fingerprint, persistent cookies, realistic request timing, and one IP per session reduce the inconsistencies that trigger verification.
-
Start with a browser-compatible HTTP client that matches common TLS and HTTP2 behavior. Reuse its cookies and network identity throughout the authorized session rather than rotating details between requests.
-
Escalate to a hardened real browser only when the response indicates a challenge. Your agent should inspect status codes, page text, iframes, and known challenge elements. Naive scrapers often treat a challenge page as valid content or retry it repeatedly, which can worsen the session score.
-
Use a residential browser proxy only when the site rejects the current network reputation and your access terms permit it. Keep the same proxy attached after the browser passes the challenge because many clearance tokens depend on the originating IP.
CAPTCHA-solving services belong at the end of this sequence. Services such as 2Captcha or CapMonster add latency, cost, and another failure point, while hidden iframes and shadow DOM can complicate challenge detection. Browserless recommends detecting the challenge first and invoking a solver only when the browser cannot complete the authorized flow through normal session handling.
Verified identity vs. evasion: Web-Bot-Auth
Web Bot Auth gives an AI agent a stable cryptographic identity instead of making it imitate a human browser. Cloudflare can verify the operator behind each request and apply access rules without forcing the agent through JavaScript or Turnstile challenges. DataDome’s Device Check reflects a similar move toward distinguishing trusted agents from abusive automation.
Web Bot Auth uses the following flow.
-
The agent operator generates an Ed25519 public and private key pair.
-
The operator publishes the public key in a signed JSON Web Key Set at /.well-known/http-message-signatures-directory over HTTPS.
-
The operator registers the agent and key directory through Cloudflare’s Bot Submission Form using request signatures as the verification method.
-
The agent signs each request with Signature, Signature-Input, and Signature-Agent headers. The signature covers request details such as the destination, key identifier, algorithm, and expiration time.
Cloudflare checks the signature against the published key. A valid request can receive verified bot status, which lets the site owner permit it without relying on fingerprint spoofing. Cloudflare’s Web Bot Auth documentation defines the registration and signing requirements.
Kernel already supports Web Bot Auth through a Cloudflare partnership. Its cloud browsers can attach the required request signatures through a Chrome extension, and Kernel offers preapproved default keys for customers that do not want to manage their own.
Web Bot Auth support provides a strong starting point, but identity alone does not provide universal access. Each site still chooses whether to accept a verified agent, and sites outside the Cloudflare verification model may continue to evaluate browser fingerprints, IP reputation, and session behavior. A browser agent therefore still needs consistent browser and session infrastructure for destinations that have not adopted verified identity.
Why humanized infrastructure still matters alongside verified identity
Web-Bot-Auth works only when the target site recognizes it. Sites without support still evaluate browser fingerprints and session behavior, while authenticated workflows still require user credentials, cookies, and browser state. Verified agent identity also does not replace user authorization for protected accounts.
Anchor combines verified identity with managed browser infrastructure for those cases. Anchor Chromium presents consistent network and runtime signals instead of the mismatched fingerprints common in basic headless browser setups. Humanized fingerprinting keeps those signals coherent throughout an authorized session rather than patching individual JavaScript properties after launch.
Session persistence provides the other required layer. Anchor can keep cookies and browser state attached to the same profile, so an agent can continue an authenticated workflow without repeatedly signing in or replaying credentials through a new browser. Stable sessions also reduce abrupt changes that bot-detection systems may treat as suspicious.
You can therefore use Web-Bot-Auth where a site accepts verified agents and use managed browser sessions where it does not. The infrastructure supports legitimate automation under the target site's access rules. It does not grant permission to ignore account restrictions, rate limits, or terms of service.
Anchorbrowser vs. DIY scraping setups
Anchorbrowser combines managed browser infrastructure with humanized fingerprints, persistent sessions, and verified identity. DIY Puppeteer setups give you more control, but you must maintain each stealth patch, proxy rule, and browser update yourself.
FAQs
-
Can stealth plugins alone bypass Turnstile, DataDome, or Akamai in 2026? No. Plugins can hide basic automation flags, but they cannot reliably match TLS fingerprints, browser-engine behavior, and session telemetry. Turnstile often requires a hardened browser or verified identity.
-
Do residential proxies guarantee access? No. Residential addresses can improve IP reputation, but detection systems also inspect TLS, HTTP/2 behavior, device fingerprints, cookies, and request cadence. Frequent rotation can break tokens bound to one IP and browser profile.
-
What is the difference between evasion and Web-Bot-Auth? Evasion makes automation resemble a human browser. Web-Bot-Auth identifies the agent through cryptographically signed requests, which lets participating sites recognize approved automation. Anchorbrowser combines Web-Bot-Auth with humanized browser infrastructure for sites that do not support verification.
-
How long do bot-detection cookies and tokens last? Lifetimes depend on the vendor and site configuration. Akamai _abck cookies may last roughly 30 minutes to two hours, according to a vendor analysis. PerimeterX _px3 estimates range from about one minute to several minutes. Persistent visitor identifiers can last much longer. Reusing a token with a different IP or fingerprint may invalidate it before expiry.
-
Is bypassing bot detection legal or compliant for AI agents? Legality depends on authorization, applicable law, site terms, data rights, and agent behavior. You should automate only permitted access, respect rate limits, and avoid circumventing access controls. Verified identity and site-approved credentials provide a clearer compliance path than concealed scraping.
Conclusion
Durable browser-agent access combines verified identity with humanized, managed infrastructure. Verified identity lets participating sites recognize authorized agents, while consistent fingerprints, network routes, and persistent sessions support legitimate automation on sites that have not adopted identity standards.
Anchor manages those browser, proxy, authentication, and security layers together. You can focus on the agent’s task instead of repeatedly patching a headless browser whenever Cloudflare, DataDome, Akamai, or HUMAN Security updates its detection methods.