puppeteer ERR_ABORTED 403 forbidden after 30 requests same session

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.