Who is Blocking You: 2026 Anti-Bot Comparison - Cloudflare, DataDome, Akamai, Kasada

You received a 403 — and the first thing people usually do is change their proxy. Sometimes it helps, but more often it doesn’t. This is because “anti-bot” is not a single technology, but at least six different systems with varying detection mechanics, strictness, and requirements for your traffic. What works against Imperva is useless against Kasada. Let's break down who is who in 2026, how to identify a vendor in 30 seconds, and what exactly to change in your proxy stack for each one.

Why "just changing the proxy" no longer works

The classic logic was simple: if the IP is blocked, just take another one. It worked as long as detection was based on the reputation of the address. Today, the IP is just one layer out of five, and its weight varies significantly among different vendors.

The common set of signals that all vendors use in one way or another:

• TLS fingerprint (JA3/JA4) — the order of cipher suites and extensions in the handshake;
• the order and case of HTTP headers — the Python client has a different order than Chrome;
• IP reputation — ASN, data center affiliation, address history;
• browser fingerprint — canvas, WebGL, hardware sensors;
• behavioral biometrics — mouse trajectories, scroll speed, input patterns.

The key takeaway, reiterated by all researchers in the field, is the importance of signal consistency. A combination of User-Agent from Chrome with a TLS fingerprint from Python marks you as a bot with any vendor — regardless of how clean your IP is. A residential address does not "override" a leaky browser layer, and vice versa.

Step one: identify the vendor by their signatures

Before making any changes, check the response headers and cookies. Each system leaves a recognizable signature — this is the fastest way to understand what you’re dealing with.

• Cloudflare — header CF-RAY, cookies cf_clearance and __cf_bm, loads challenge.js; in newer builds, you might see the header cf-mitigated.
• DataDome — cookies datadome and _dd_s, script tags.js.
• Akamai — cookie _abck, reference header akamai-grn.
• PerimeterX (HUMAN Security) — cookies _px3, _pxvid, _pxhd, scripts px.js or d.js.
• Kasada — headers of the x-kpsdk-* family (ct — challenge token, dv — device validation, cd — challenge data, v — version), cookie KP_UIDz, scripts ips.js or p.js.
• Imperva (Incapsula) — cookies incap_ses_*, visid_incap_*, reese84.
• AWS WAF — cookie aws-waf-token, calls the endpoint /challenge.js.
• F5 / Shape Security — cookies with the prefix TS (for example, TS01a2b3c4).

A separate marker is the nature of the denial. Kasada responds with a "bare" 429 without a response body: if you see 403 or 429 along with headers x-kpsdk-*, the question is settled. DataDome more often returns a 403 with a CAPTCHA page. Cloudflare presents an interactive challenge or Turnstile.

How systems differ in mechanics

The signature tells you "who," but the tactic defines "how." Architecturally, vendors diverge significantly.

Cloudflare — global models at the edge of the network

Operates at the CDN edge level: the decision is made before the request reaches the application. The models are global, trained on the traffic of the entire network — about one-fifth of the websites on the internet. The plus for you: behavior is predictable, and experience from one site transfers to another. The downside: the network sees your subnet across thousands of resources simultaneously, and reputation accumulates quickly.

DataDome — a personal model for each site

The key difference: the platform maintains about 85,000 client ML models trained on the traffic of specific sites and processes over 5 trillion signals per day with a response time of less than 2 milliseconds. The practical consequence is simple and unpleasant: each protected site is a separate task. A working setup for Etsy does not transfer to another resource under the same vendor. In 2025, intent analysis was added (assessing the purpose of the visit, not just the fact of automation) and separate categorization of LLM crawlers.

Akamai — focus on TLS and telemetry

Checks handshake signals and validates behavioral telemetry on its side through cookie _abck. According to independent measurements from 2026, Akamai and Imperva challenge default automated clients less often than Cloudflare and DataDome — but this does not mean "weaker": where it is set aggressively, bypassing requires a correct TLS layer, not just changing the IP.

PerimeterX / HUMAN — network reputation

The client's reputation spreads across the vendor's entire network. If you get flagged on one site, you arrive on another already marked. Typical platforms include e-commerce and real estate.

Kasada — active interrogation of the environment

The strictest of the mass systems. It not only collects fingerprints but actively interrogates the environment: inspects client code via Function.prototype.toString(), applies anti-deobfuscation to its own scripts. According to aggregate assessments of complexity, it receives extreme ratings for both the sophistication of detection and the labor intensity of self-bypassing. It is used in ticketing and real estate.

Imperva (Incapsula) — WAF logic by default

Starts with IP and WAF rules; behavioral layers are activated at higher settings. Classic platforms include corporate websites and job boards.

Who is stricter: numbers instead of feelings

There is an independent benchmark Scrapeway: eight services against eleven targets, over 1000 requests per service per target, two reports per month. Targets are assigned to vendors — Indeed under Cloudflare, Etsy under DataDome, Walmart and Zillow under PerimeterX, Realtor under Kasada.

What the measurements of 2026 show:

• High strictness — Cloudflare, DataDome, PerimeterX, Kasada: the overwhelming majority of default, unconfigured automated clients receive a challenge.
• Moderate — Akamai and Imperva: challenge default clients noticeably less often.
• Against Cloudflare targets, only a small fraction of unconfigured clients consistently received page content.

For comparison: for specialized bypass services, success against these targets ranges from 94–100% depending on the vendor — meaning the task is solvable, but not with a default client and not just by changing the IP.

What to change in the proxy stack for each

Now for the practical part. Below is not a recipe for bypassing, but the logic for selecting infrastructure based on the type of detection.

1. Imperva and AWS WAF. The weight of the IP is high, and behavioral layers are often turned off. Here, data center proxies still work — provided there are clean subnets and a reasonable rate. Start here, as it is the cheapest in terms of traffic.
2. Akamai. Proxies matter less than the TLS layer. First, fix the handshake and the order of headers, and only then upgrade the IP class. Changing the proxy with a faulty JA4 fingerprint won’t yield anything.
3. Cloudflare. Global reputation means that the subnet burns out quickly and immediately everywhere. You need residential proxies with a wide pool and reasonable rotation: not "a new IP for every request," but maintaining the session for the duration of the logical task, otherwise cf_clearance will break.
4. DataDome. The model is trained on the traffic of a specific site, so the most important factor is the consistency of your behavior specifically on it. A residential IP provides a positive trust score because real people browse from residential connections — but by itself, without managing the browser fingerprint, it guarantees nothing. Do not blindly transfer settings from one site to another. Details on this vendor’s specifics can be found in the analysis of proxies for DataDome.
5. PerimeterX / HUMAN. Since reputation is network-based, isolation is more important than volume: different projects require different pools so that a mark from one site does not carry over to others.
6. Kasada. Data center addresses are filtered at the entrance. The working minimum is residential, but preferably mobile proxies: behind one mobile IP through CGNAT sit hundreds of real subscribers, and it is more costly for the system to ban such an address. Additionally, it is essential to match the User-Agent to the current version of the browser — an outdated string instantly reveals the bundle.

The main mistake: heterogeneous stack

Let’s reiterate what we started with, as this is the reason for most "unexplained" bans. All six systems catch asynchrony between layers. A residential IP from Germany + system timezone UTC + TLS fingerprint from curl + fresh Chrome in User-Agent — this is not "almost passed," this is a ready bot profile. The proxy is responsible for exactly one layer out of five; the other four reside in your client.

From this, the practical order of operations is: first, identify the vendor by signature, then assess which layer is the weakest, and fix it — rather than the one that is easier to change. If after fixing the stack the targets remain inaccessible, the question shifts to "build it yourself or pay for a ready-made solution" — this fork was discussed in the article proxies vs scraping APIs and web unblockers.

In brief

There is no single "anti-bot," nor is there a universal bypass — no technique works against all eight systems at once. Identify the vendor by cookies and headers (this takes 30 seconds), understand its mechanics — IP weight for Imperva, TLS for Akamai, global reputation for Cloudflare, personal site model for DataDome, network marking for PerimeterX, active interrogation of the environment for Kasada — and select the type of proxy accordingly, rather than at random. Use data centers where they look at the IP formally; residential where they consider trust; mobile where the network strictly filters out all server-based connections. And ensure consistency across all layers: it is precisely on this that most seemingly correctly configured projects fail.