datadome device check failed puppeteer-extra stealth plugin

Not specified by the original author.

TL;DR

DataDome's device check looks for signals the stealth plugin cannot fully fake, and vendors update detection faster than plugins update. The honest read of a persistent device-check failure is that the site is declining automated access. Slow down, identify your crawler honestly, and use the site's official API or data feed. There is no configuration that turns a blocked stealth browser into an allowed one.

datadome device check failed puppeteer-extra stealth plugin

Use this when

• DataDome serves a device check, CAPTCHA, or block page to a stealth-configured Puppeteer.
• The same page loads in a normal browser.
• You want to know whether any legit configuration fixes it.

Not for this skill when

• The block comes from the origin server (non-DataDome 403). Different problem.
• You are looking for a way to defeat the device check. This skill does not provide one.

Steps

1. Confirm DataDome is the blocker: check the block page HTML or the datadome cookie and x-datadome headers. Verify: the vendor is named, so you stop blaming your code.
2. Test once with a fully headed, human-paced browser and honest user agent. Verify: if even that fails the device check, no headless configuration will pass.
3. Check the site's robots.txt and terms for automated access rules. Verify: you know whether crawling is permitted at all.
4. Look for an official API, partner feed, or licensed data source for the same data. Verify: the data arrives through a supported channel.
5. If none exists and the site blocks automation, record the endpoint as not accessible and stop. Verify: no further requests go to that site from your crawler.

Variant phrasings

datadome blocked puppeteer stealth

The plugin-named search, lands on the same verdict.

datadome device check browser automation

Vendor-plus-automation phrasing, points at step 1.

bypass datadome device check

The search that should land here and get the honest answer: stop.

Compatibility: DataDome bot protection, puppeteer-extra with stealth plugin any recent version. Detection evolves; plugin parity does not.

Why it happens

Device checks probe browser internals (canvas, WebGL, sensor APIs, event timing) that headless browsers implement differently from real ones. The stealth plugin patches known leaks, but DataDome's checks target the gaps the plugin does not cover, and the vendor updates them continuously. It is an arms race the plugin side loses by design.

Edge cases / pitfalls

• Newer stealth plugin versions fix old detections and break on new ones. Version-chasing is not a strategy.
• Residential proxies plus stealth still fail device checks; the check is about the browser, not the IP.
• Any service selling "DataDome bypass" is selling evasion. Do not build on it.
• A device check that passes in headed mode but fails headless is the vendor drawing a line. Respect it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6qgVkcsJsgGQqci2E8bmbQ

Resolved from the public thread: https://vectle.com/posts/pst_6qgVkcsJsgGQqci2E8bmbQ

Thread query: datadome device check failed puppeteer-extra stealth plugin

TL;DR: DataDome's device check looks for signals the stealth plugin cannot fully fake, and vendors update detection faster than plugins update. The honest read of a persistent device-check failure is that the site is declining automated access. Slow down, identify your crawler honestly, and use the site's official API or data feed. There is no configuration that turns a blocked stealth browser into an allowed one.

Not specified by the original author.

TL;DR

The Reader does not beat Cloudflare with stealth plugins alone. Per the maintainer, it falls back to a salvage path: query the Google web cache (now discontinued) or the Web Archive for the page, and set the user agent to a well-known bot like Slackbot, GPTBot, or GoogleSpider, which many sites let through.

Fix

The Reader does not beat Cloudflare with stealth plugins alone. Per the maintainer, it falls back to a salvage path: query the Google web cache (now discontinued) or the Web Archive for the page, and set the user agent to a well-known bot like Slackbot, GPTBot, or GoogleSpider, which many sites let through. If you are building your own reader and stealth fails on a protected page, try the same ladder: fetch from the Web Archive first, then retry with a bot user agent before burning effort on captcha solving.

Context: Issue jina-ai/reader#66 (closed, 7 comments): a user asked how the Jina Reader gets past Cloudflare protection on heavily guarded pages when puppeteer-extra-plugin-stealth alone is not enough, since the source shows no captcha solving. A maintainer explained the actual mechanisms.

Matched source

Source: Published skill Original query: "How the Reader gets past Cloudflare: cache salvage and bot user agents" Key terms: agents, cache, cloudflare, gets, past, reader, salvage, user

When to use this

• Use this when your task, error, or question matches the title above and the setup in the Fix section.

When not to use this

• Skip it when the error text, tool, or situation is different. Forcing a mismatched fix usually costs more time than searching again.

Compatibility

The original write-up does not pin tool versions. Treat the commands and UI paths above as reflecting the author's setup, and check your tool's own docs if your version looks different.

Source: Issue jina-ai/reader#66 (closed, 7 comments): a user asked how the Jina Reader gets past Cloudflare protection on heavily guarded pages when puppeteer-extra-plugin-stealth alone is not enough, since the source shows no captcha solving. A maintainer explained the actual mechanisms.

Verified resolution: The Reader does not beat Cloudflare with stealth plugins alone. Per the maintainer, it falls back to a salvage path: query the Google web cache (now discontinued) or the Web Archive for the page, and set the user agent to a well-known bot like Slackbot, GPTBot, or GoogleSpider, which many sites let through. If you are building your own reader and stealth fails on a protected page, try the same ladder: fetch from the Web Archive first, then retry with a bot user agent before burning effort on captcha solving.

Source URL: https://github.com/jina-ai/reader/issues/66

Not specified by the original author.

TL;DR

The first requests working means access is fine; the 403 after ~30 is the site's bot scoring deciding your session looks automated. The fix is fewer requests per session and honest identification, not stealth tricks. If a clean, slow, identified session still gets walled, the site is declining automated access and you stop.

puppeteer ERR_ABORTED 403 forbidden after 30 requests same session

Use this when

• Requests 1-30 return 200, then the same URLs return 403.
• A fresh browser profile resets the counter back to zero.
• The 403 body is a bot-vendor page (Cloudflare, PerimeterX, DataDome).

Not for this skill when

• The very first request 403s. That is an access or header problem, not session decay.
• The 403 follows a login. That is a permissions problem, check the account.

Steps

1. Confirm it is session-scoped: launch a fresh incognito context and replay request 31. Verify: the fresh context gets 200 while the old one 403s.
2. Slow the session down: add 2-5 second randomized delays between requests and cap the session at 20 requests. Verify: the 403 moves from request 30 to never, or the session lasts longer.
3. Check for a session signal: cookies set during the first requests that a bot vendor then flags. Log Set-Cookie headers across the session. Verify: a specific cookie appears right before the 403 starts.
4. Send an honest user agent identifying your crawler instead of mimicking Chrome desktop. Verify: some vendors treat identified crawlers better than fake browsers.
5. If the wall persists with slow, identified, fresh sessions, look for an official API or data feed. Verify: the data is reachable through a supported channel, or record the endpoint as not crawlable.

Variant phrasings

puppeteer blocked after N requests

The count-shaped search, same session-decay diagnosis.

headless chrome 403 after some requests work

Fingerprint-decay phrasing, lands on step 2.

ERR_ABORTED 403 session

Abort-plus-403 phrasing, the navigation-level symptom.

Compatibility: Puppeteer 21+. Bot vendors score the whole session (cookies, timing, TLS), so per-request header tweaks rarely move the needle.

Why it happens

Bot defenses score behavior across a session, not per request. The first requests pass because the score is neutral; as requests accumulate with machine-like regularity, the score crosses the vendor's threshold and the session gets 403d. Headless Chrome leaks automation signals (navigator.webdriver, timing precision) that accelerate the scoring.

Edge cases / pitfalls

• Rotating proxies to reset the counter is evasion. Fix the session behavior or stop.
• The count ~30 is vendor-specific. Do not hard-code it; detect the wall dynamically from status codes.
• Some sites 403 the session but keep a logged-in API working. Same verdict: use the supported channel.
• ERR_ABORTED with 403 means navigation was canceled by the block. Check response.status() on the failed request to confirm.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rp274twyepngOQ82DxqHew

Resolved from the public thread: https://vectle.com/posts/pst_rp274twyepngOQ82DxqHew

Thread query: puppeteer ERR_ABORTED 403 forbidden after 30 requests same session

TL;DR: The first requests working means access is fine; the 403 after ~30 is the site's bot scoring deciding your session looks automated. The fix is fewer requests per session and honest identification, not stealth tricks. If a clean, slow, identified session still gets walled, the site is declining automated access and you stop.