Why Am I Getting Blocked

A 403 from ASN filtering and a 403 from TLS fingerprinting look identical in the response. A CAPTCHA triggered by IP reputation and a CAPTCHA triggered by behavioral detection look identical. The target does not disclose which detection layer produced the response. The failure mode is visible; the cause is not.

This is why the default response — switch proxy providers — fails most of the time. Provider switches address IP-layer signals. They do nothing to TLS fingerprints, behavioral patterns, or JavaScript challenge requirements. If the layer that blocked you isn't the IP layer, no provider switch will resolve it.

Layer 1 — IP reputation and ASN classification. The target queries IP intelligence databases and evaluates the requesting IP's ASN type (commercial vs residential), geolocation, abuse history, and blocklist membership. This is the layer proxies directly address. Fix: change proxy type (datacenter → ISP → residential → mobile) or change provider pool quality.

Layer 2 — TLS fingerprinting. The target reads the ClientHello from your TLS handshake — cipher suite order, extension list, supported groups — and computes a fingerprint. Python requests, Go net/http, and Node axios each have fingerprints that detection databases associate with automated clients. This layer fires before any HTTP request data is processed. Fix: TLS patching libraries (curl-impersonate, tls-client) that produce browser-matched fingerprints.

Layer 3 — behavioral detection. The target observes request timing, navigation sequences, resource loading patterns, and interaction signals across multiple requests. Uniform timing intervals, absence of resource requests alongside HTML, and sequential URL patterns are machine-traffic signals. This layer accumulates over a session — it rarely fires on the first request. Fix: timing jitter, resource loading, navigation randomization in the scraper client.

Layer 4 — JavaScript challenge evaluation. The target serves a challenge that requires executing JavaScript in a real browser environment. It probes for browser API availability, canvas fingerprints, WebGL renderer strings, and headless browser indicators. HTTP-based scrapers cannot solve this. Fix: browser automation (Playwright, Puppeteer) with headless detection patches.

Block on the first request, clears when switching to residential proxies. Layer 1 was the trigger — ASN classification blocked the commercial IP. The residential classification passed the filter. No other changes needed at this stage.

Block on the first request, persists with clean residential IPs across multiple providers. Layer 2 is the most likely trigger — the TLS fingerprint identifies your client as non-browser before the IP even matters. Confirm with the browser test: if a browser through the same IP passes, TLS is the variable. Apply TLS patching before changing proxy providers again.

Block appears after 5–20 successful requests, not on the first. Layer 3 — behavioral accumulation. The scraper's request pattern triggered detection after enough signal was collected. Uniform timing and absent resource loading are the usual causes. Add jitter, load associated resources, vary navigation. The proxy is not involved in this failure.

Challenge page appears that requires human interaction or doesn't resolve automatically. Layer 4 — JavaScript challenge. The challenge requires browser execution that your HTTP client cannot provide. Upgrade to browser automation. If the challenge persists even in headless browser, apply stealth patches (playwright-extra stealth plugin, puppeteer-extra) to mask headless indicators.

Block rate constant across all proxy types — datacenter, residential, ISP, mobile. The detection layer is not IP-based. Layers 2, 3, or 4 are firing. The IP classification is irrelevant. Stop changing proxy types and fix the client stack.

Hardened targets — enterprise e-commerce, major social platforms, search engines at volume — implement all four layers simultaneously. Clearing one layer exposes the next. This is why partial fixes produce partial improvements: residential proxies improve success rate from 0% to 40%, but the remaining 60% is behavioral and TLS signals that residential classification doesn't influence.

Address layers in order. Fix Layer 1 first (proxy type). Confirm with the browser test whether Layer 2 is now the binding constraint. Fix Layer 2 (TLS patching). Confirm whether behavioral signals are now the binding constraint. Fix Layer 3 (client behavior). Layer 4 (JS challenges) is the last resort — it's the most resource-intensive to address and only required when the previous three layers are satisfied.

Skipping the sequence and going straight to Layer 4 (browser automation) wastes resources on targets where the block is a Layer 1 issue that a proxy type change would resolve in minutes.

If your block clears with residential proxies but not datacenter: the problem is ASN classification. You've confirmed Layer 1. Find the right residential provider for your workload.

If your block persists across all proxy types with the same scraper client: TLS fingerprint or behavioral signals are the binding constraint. The browser test confirms which. Stop switching providers — change the client stack.

If your block appears mid-session after several successful requests: behavioral accumulation is the trigger. Proxy changes will not fix this. Request pattern modification is the fix.

If CAPTCHAs appear on the first request with clean residential IPs: TLS fingerprint is the most likely trigger before behavioral signal has had time to accumulate. Patch TLS first.

If your setup worked last week and fails this week with no changes on your end: the target updated its detection policy. Run the browser test again — the new blocking layer may be different from the one you originally addressed.