How anti-bot systems decide you are a bot

People treat getting blocked as one event with one cause. It is not. Commercial anti-bot systems build a risk score from several independent layers, and a browser only controls some of them. Knowing which layer flagged you decides whether the fix is a better proxy, a better fingerprint, or slowing down.

Roughly in the order a request encounters them:

1. Network reputation

Before a single byte of your page executes, your IP has a reputation. Datacenter ranges are labelled as such and are trivially identified. Residential and mobile addresses look better, but a residential IP that hundreds of scrapers have already burned is worse than a clean datacenter one.

ASN, whether the range is a known VPN or proxy provider, and the recent history of that specific address all feed in. This layer runs before JavaScript, which is why a perfect fingerprint on a burnt IP still fails.

2. TLS and HTTP fingerprinting

Your TLS client hello has an order of cipher suites, extensions and elliptic curves that differs between implementations. JA3 and JA4 hash exactly that. HTTP/2 adds its own: frame settings, header ordering, priority.

This is why a Python or Node HTTP client with a copied Chrome user agent is caught instantly. The header says Chrome, the handshake says something else, and the contradiction is visible before any content is served. A real browser does not have this problem, which is one of the underrated reasons to use one.

3. Browser fingerprint and automation tells

Now JavaScript runs. Two categories:

Automation artefacts. navigator.webdriver, CDP traces, a missing or wrong chrome object, permission states that contradict the notification API, an implausible plugin array. Stealth patches target this list, which is why the list keeps growing.

Coherence. More important and less discussed. Does the user agent agree with navigator.platform and the platform client hint? Does the timezone match the IP's geography? Are the fonts the ones that OS ships? Is the WebGL renderer a GPU that actually exists, and one that belongs on the claimed OS? A single contradiction here outweighs a dozen ordinary values.

And the temporal question nobody tests: is the canvas hash the same as last visit? Real hardware is deterministic. A returning user whose GPU changed overnight is a stronger signal than most single-page tells.

4. Behaviour

Mouse paths, scroll velocity, keystroke timing, dwell time, whether you moved before clicking, whether you clicked the exact centre of every button. Humans are noisy and slow; scripts are precise and fast.

Kasada and DataDome also ship proof-of-work and integrity challenges: a computation the client must perform correctly, in a real engine, within a plausible time. That is what a 429 from Kasada often is, not a rate limit but a challenge you failed to solve.

This layer is entirely on you. No browser makes a script behave like a person.

5. History and context

The oldest and most decisive layer, and the one the whole industry underweights. What has this account done? How old is it? Did it appear from Frankfurt yesterday and act from Singapore today? Do a hundred accounts share one payment method or one recovery email?

You can be perfect on layers 1 through 4 and still be actioned on layer 5, because the account's own history is the evidence.

What this means practically

The layers are independent, so diagnose before you fix:

• Blocked before the page renders, no JavaScript executed: layer 1 or 2. Get a better proxy. A fingerprint change will not help.
• The page loads, then a challenge appears: layer 3 or 4. Check coherence first, then slow down.
• You pass everything but the account is actioned anyway: layer 5. No tool fixes this. Time and plausible history do.

An antidetect browser addresses layers 2 and 3, and helps with 1 by binding a proxy to the identity so timezone and locale follow the exit IP. It does nothing for 4 and 5, and any vendor implying otherwise, ourselves included, is selling.

Verify rather than assume

Public detectors let you check layers 2 and 3 cheaply: whoer.net for IP and timezone coherence, CreepJS for deep consistency. Neither predicts a specific vendor's decision, so finish by testing the wall you actually have to clear.

Our own consistency checklist covers layer 3 in detail, and the free tier is enough to run all of it.