Akamai Bypass: How to Get Past Akamai Bot Detection in 2026

TL;DR

• Akamai stacks multiple detection layers (IP reputation, TLS fingerprinting, browser and device fingerprinting, and behavioral analysis) and scores them together to separate real users from bots.
• Confirm a site runs Akamai by checking for tells like the X-Akamai-Transformed header and the _abck and ak_bmsc cookies.
• A reliable bypass combines several techniques: a TLS-impersonating client like curl_cffi, browser-matched headers, rotating residential IPs, and a real browser engine for JavaScript challenges.
• No single layer is enough on its own, and open source bypass tools get flagged over time as Akamai reverse-engineers their signatures.
• Managed solutions like Decodo's Web Scraping API handle fingerprinting, proxy rotation, and challenges in one request, removing the ongoing maintenance burden.
• Bypassing bot detection to collect public data is different from exploiting a security flaw, so know where the technical, ethical, and legal lines sit before you scrape.

Akamai security mechanisms overview

Before you can get past Akamai, you need to understand what it's actually looking at. The good news: you don't need a security degree to get the gist. Akamai runs a series of checks, and each one is trying to answer the same question from a different angle: "Is this a real person or a script?"

Let's walk through the layers.

What Akamai actually is

Akamai started as a CDN (content delivery network), which is infrastructure that sits between visitors and a website's origin servers to deliver content faster. Because it already sits in that middle position, seeing every request before it reaches the site, it's in a perfect spot to also act as a security checkpoint. That's where Akamai Bot Manager comes in: the bot detection layer that inspects traffic and decides what gets through.

So when you send a request to an Akamai-protected site, you're not talking directly to the site. You're talking to Akamai first, and it decides whether to pass you along.

The detection layers

Akamai stacks several checks on top of each other. A scraper usually has to satisfy all of them, not just one.

• Network and request analysis. The first and cheapest of checks. Akamai looks at your IP address and its reputation (has it misbehaved before, is it a known datacenter address), and it inspects low-level details of how your connection is made. This includes your TLS fingerprint, which is essentially the signature your client leaves during the encrypted handshake. Real browsers have well-known fingerprints. Default Python and Node HTTP clients have very different ones, and Akamai knows the difference.
• Device and browser fingerprinting. Akamai runs JavaScript in the page that quietly collects dozens of signals about your environment: screen resolution, operating system, browser version, installed fonts, timezone, graphics rendering quirks, and more. A real browser produces a consistent, believable set of values. A headless script often produces missing, contradictory, or obviously automated ones.
• Behavioral analysis. The hardest layer to fake. Akamai watches how you interact with the page: mouse movement, scroll patterns, keystroke timing, how you navigate from one page to the next. Humans are a little messy and irregular. Bots tend to be too fast, too precise, or too repetitive.

How Akamai scores traffic

Akamai doesn't just return a simple yes or no. It assigns a bot score based on everything above, then acts on that score. Depending on how suspicious you look, it will:

• Allow the request through if you look human enough
• Serve a CAPTCHA or a JavaScript challenge to test you further
• Block you outright by returning a 403 or similar

The more layers you fail, the worse your score, and the more likely you're to get challenged or blocked.

How to tell if a site uses Akamai

Before you spend time planning around Akamai, confirm the site actually uses it. Two easy tells:

• Response headers. Akamai often leaves fingerprints in the headers, like X-Akamai-Transformed. You can see these in your browser's DevTools Network tab or with a quick curl -I against the site.
• Cookies. Akamai Bot Manager sets characteristic cookies, most notably _abck and ak_bmsc. If you see those in the response, Bot Manager is running.

A browser extension like Wappalyzer can also detect Akamai automatically, which is the fastest way to check.

With the detection stack clear, the next sections cover how each layer can be satisfied, starting with the strategic approaches and then the request-level implementation. For broader context beyond Akamai specifically, our guides on navigating anti-bot systems and anti-scraping techniques cover the wider landscape.

Bypass techniques and strategies

Here are the main approaches to getting past Akamai, ordered roughly from least to most reliable. None of these is a silver bullet on its own. The layers stack, so your bypass usually has to as well.

Direct-to-origin requests

The idea here is to skip Akamai entirely by finding the site's real origin server IP and talking to it directly, going around the checkpoint instead of through it. In practice, this rarely works against a properly configured site, because the origin is set up to reject any request that didn't come through Akamai. It's also a legally and ethically grey approach that Akamai treats as a security issue rather than normal scraping, which we'll cover later. For most scrapers, this is a dead end.

Matching Akamai's expected browser signals

Every real browser sends a predictable set of headers, in a specific order, using modern protocol features like HTTP/2. Default scraping libraries often send too few headers, in the wrong order, or over older HTTP versions, which stands out immediately. Constructing your requests to match what a real Chrome or Firefox would send (the right headers, the right order, HTTP/2 support) clears the most basic layer of detection.

Spoofing TLS fingerprints

As covered earlier, your TLS handshake leaves a signature, and default Python or Node clients don't match any real browser. Akamai flags that mismatch instantly. TLS-impersonation libraries (like curl_cffi) rewrite your client's handshake so it presents as a genuine Chrome or Firefox fingerprint. This is one of the highest-impact single changes you can make, because it addresses a layer that plain header spoofing can't touch.

Rotating residential or mobile IPs

Akamai scores IP reputation heavily, and datacenter IPs (the kind cloud servers use) are flagged fast. Residential proxies route your traffic through IPs assigned by real ISPs to real homes, so your requests look like ordinary users rather than server traffic. Pair that with rotation so requests spread across many addresses instead of hammering from one, and you sidestep both the reputation flag and the volume-based blocks.

Running real or realistic browser engines

Header and TLS spoofing get you past the network layer, but they don't execute JavaScript, so they can't satisfy Akamai's device fingerprinting and challenge scripts. For that, you need a real browser engine (or a close imitation) driven by automation tools like Playwright or Puppeteer. A real browser runs Akamai's sensor scripts and produces believable fingerprint values, which is often the only way past the JavaScript layer. The tradeoff is speed and resource cost, since running browsers is far heavier than sending raw requests.

Pacing and randomizing requests

Even with everything above configured perfectly, behaving like a machine gives you away. Firing requests at a constant, rapid interval is an obvious bot pattern. Adding realistic delays between requests, randomizing the timing, and avoiding perfectly regular navigation patterns helps you slip under the behavioral layer. It's the least technical technique on this list, but ignoring it undoes a lot of the work the other layers put in.

Payloads and technical implementation

This section walks through the request-level configuration a scraper actually needs to get past Akamai's network layer: the TLS handshake, the headers, and routing through a residential proxy. We'll use Akamai's own site, akamai.com, as the test target, since it's (unsurprisingly) protected by Akamai Bot Manager.

A quick note on scope: "payloads" here means the request configuration you send, not attack payloads. We're satisfying Akamai's checks to collect a public page, not exploiting a vulnerability.

Step 1: Confirm the target runs Akamai

Before writing any code, verify the target actually uses Akamai. A quick header check does it:

curl -I https://www.akamai.com/

Look for Akamai's tells in the response: headers like X-Akamai-Transformed, Akamai-GRN, and _abck or ak_bmsc cookies in the Set-Cookie lines. There isn't a guarantee it will show up on a silver platter, so browser extensions like Wappalyzer can be required to confirm. Once you've verified Bot Manager is running, you know what you're up against.

Step 2: the baseline test (which will fail)

Start by sending a plain request with a default HTTP client, so you can see the block for yourself:

import requests

response = requests.get("https://www.akamai.com/")
print(response.status_code)

Against an Akamai-protected target, a plain client like this typically comes back with a 403 Forbidden or gets served a challenge page instead of the real content. Nothing you did was wrong syntactically. Akamai just took one look at the request and knew it wasn't a browser.

Step 3: Understanding the TLS fingerprint problem

When your client opens an HTTPS connection, it sends a "client hello" message that describes which TLS version, cipher suites, and extensions it supports, in a specific order. That combination is distinctive enough to fingerprint.

Here's the problem: Python's Requests (which uses urllib3) and Node's default clients produce TLS fingerprints that no real browser produces. Akamai maintains a catalog of what real browsers look like, so a Python fingerprint sticks out like a sore thumb. You can spoof every header perfectly and still get blocked at this layer, because the handshake gave you away before a single header was read.

Step 4: Configuring a TLS-impersonating client

The fix is a client that mimics a real browser's handshake. curl_cffi is the go-to library for this in Python, since it wraps curl-impersonate and can present a genuine Chrome or Firefox fingerprint.

Install it:

pip install curl_cffi

Then make the same request with impersonation turned on:

from curl_cffi import requests

response = requests.get(
    "https://www.akamai.com/",
    impersonate="chrome136",
)
print(response.status_code)

The impersonate="chrome136" argument tells curl_cffi to replicate Chrome 136's entire TLS handshake, cipher order and all. This single change clears the TLS layer that stopped the plain client.

Step 5: Matching headers and header order

A real browser sends a specific set of headers, in a specific order. curl_cffi's impersonation handles most of this automatically when you set an impersonation target, but if you're adding custom headers, keep them consistent with the browser you're impersonating. Order matters, and curl_cffi preserves the order you define:

from curl_cffi import requests

headers = {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
}

response = requests.get(
    "https://www.akamai.com/",
    impersonate="chrome136",
    headers=headers,
)
print(response.status_code)

Avoid adding headers a real browser wouldn't send, or ordering them in a way Chrome never would. Consistency between your claimed identity (Chrome) and your actual behavior is the whole game.

Step 6: Routing through a rotating residential proxy

TLS and headers get you past protocol-level checks, but if your IP is a flagged address, Akamai blocks you regardless. Chaining the impersonated client through a residential proxy solves the reputation problem. Here's the full setup with Decodo's rotating residential endpoint. You can get the proxy credentials from the Decodo dashboard.

from curl_cffi import requests

proxy = "http://username:password@gate.decodo.com:7000"
proxies = {"http": proxy, "https": proxy}

headers = {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Upgrade-Insecure-Requests": "1",
    "Sec-Fetch-Dest": "document",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-User": "?1",
}

response = requests.get(
    "https://www.akamai.com/",
    impersonate="chrome136",
    headers=headers,
    proxies=proxies,
    timeout=20,
)

print("Status:", response.status_code)

With a browser-matched TLS fingerprint, consistent headers, and a residential IP, this request has a much better chance of returning a 200 OK and the real page content, where the plain client got a 403. The rotating endpoint assigns a fresh IP per request, so scaling up doesn't concentrate traffic on a single address.

Practical tips

• Pin the impersonated browser version, then revisit it. chrome136 is a real, current target, but fingerprint databases update as browsers release new versions. A target that's fresh today can drift out of date. Check periodically that you're impersonating a version that's still in common use.
• Isolate failures with a clean session. If you're getting blocked, test one variable at a time. Try the impersonated client without a proxy, then with one, from a fresh session. That tells you whether TLS, headers, or IP reputation caused the block, instead of guessing.

For header syntax fundamentals, see how to send HTTP headers with cURL. And if you'd rather handle fingerprint spoofing at the browser level instead of the request level, Camoufox is a solid alternative approach.

Limitations and challenges in bypass

Everything above can work, but none of it stays working effortlessly. Here's where do-it-yourself Akamai bypass runs into trouble:

• It's a cat-and-mouse game. Open source impersonation tools are public, which means Akamai can study them too. Once a library's fingerprint becomes popular enough, its signature gets cataloged and flagged, so the tool that worked last quarter can quietly stop working this one.
• One layer solved doesn't mean all layers solved. A perfect TLS fingerprint does nothing if your IP reputation or behavioral pattern still trips the alarm. The layers are cumulative, so a single weak link sinks the whole session.
• Framework lock-in. Some impersonation and anti-detect tools integrate cleanly with only one scraping framework, which complicates things when you need proxy rotation, retries, or to swap components later.
• JavaScript and behavioral checks are the real wall. Satisfying these usually requires a real or heavily instrumented browser, which is slower, heavier, and far more resource-intensive than sending raw requests. At scale, that cost adds up fast.
• Detection rules change without notice. Akamai updates its logic frequently, so a bypass that runs fine today can degrade tomorrow with no warning and no error message telling you why.

The short version: a working bypass isn't a one-time build; it's ongoing maintenance, and that maintenance cost is what pushes many teams toward a managed solution. For background on the hardest layer, see scraping dynamic content, and for the browser automation tradeoffs, Playwright vs. Selenium in 2026.

Tools and solutions for bypass

Once you understand the layers, the question becomes which tools to actually use, and how much of the work you want to own yourself. Here are the main options, from fully hands-on to fully managed.

The open source stack

For teams building their own bypass, the toolkit usually combines a TLS-impersonating HTTP client with browser automation for the JavaScript-heavy pages.

• curl_cffi. The Python go-to for TLS impersonation, as used in the code above. Presents real Chrome and Firefox fingerprints at the request level. Fast and lightweight, but it doesn't execute JavaScript, so it can't handle challenge scripts alone.
• Playwright and Puppeteer. Full browser automation. They run a real browser engine, so they execute Akamai's sensor scripts and produce believable device fingerprints. The tradeoff is speed and resource cost, since you're running actual browsers.
• tls-client(Go/Python). Another TLS-impersonation option, popular for its performance and used in higher-throughput setups.

Anti-detect browsers

A middle ground between raw requests and standard automation. Camoufox is a hardened Firefox build designed specifically for scraping, with fingerprint spoofing baked in at the browser level rather than the request level. Useful when you need a real engine but want the fingerprinting handled for you.

Managed scraping APIs and unblockers

If all of the above sounds like too much work, what if you make a single API call and let a tool handle fingerprinting, proxy rotation, and challenge handling for you? Decodo's Web Scraping API handles the entire Akamai stack behind one request: browser-level rendering, TLS fingerprint matching, residential proxy rotation across 115M+ IPs, and anti-bot bypass. You send a URL, you get clean HTML back.

import requests

url = "https://scraper-api.decodo.com/v2/scrape"

payload = {
    "target": "universal",   # generic scraper for any URL
    "url": "https://www.akamai.com/",
    "headless": "html",       # render with a headless browser (clears JS challenges)
}

headers = {
    "accept": "application/json",
    "content-type": "application/json",
    "authorization": "Basic YOUR_TOKEN_HERE",  # from the Decodo dashboard
}

response = requests.post(url, json=payload, headers=headers)
print(response.status_code)
print(response.json())

Comparison

Build vs. buy

The decision usually comes down to two questions: how much are you scraping, and how business-critical is the target?

Building your own stack makes sense for low volumes, learning projects, or when you need fine-grained control over every layer. It's cheaper per request when everything works, and it teaches you how the detection actually behaves.

Buying makes sense when the target is business-critical, and downtime costs you real money, when your volume is high enough that maintenance becomes a full-time job, or when you'd simply rather your engineers work on your product instead of chasing Akamai's latest fingerprint update. Decodo's Web Scraping API and Site Unblocker exist for exactly this: they absorb the maintenance treadmill so you don't have to.

If you're dealing with a mixed anti-bot landscape (Akamai on one target, Cloudflare on another), the Cloudflare bypass guide is a useful sibling to this one. And for the browser automation route specifically, see the Playwright web scraping tutorial.

Security, legal, and ethical considerations

With Akamai, there's a real line between "scraping public data" and "poking at someone's security," and it's worth knowing where that line sits. To be clear upfront: this is general information, not legal advice, and the specifics vary by jurisdiction and situation. For a fuller treatment, see our guide on whether web scraping is legal.

Bypassing bot detection vs. exploiting a vulnerability

There's an important distinction between getting past bot detection to collect public data and exploiting an actual security flaw. Configuring a realistic browser fingerprint to read a public product page is fundamentally different from probing for a misconfiguration that exposes a site's origin server.

Akamai itself draws this line. Its own security research (the BreakingWAF work) focuses on origin exposure and misconfigurations, meaning cases where a site's real server can be reached directly because it wasn't locked down properly. Reaching an origin that way isn't scraping; it's touching infrastructure that was never meant to be publicly accessible, and Akamai treats it as a security issue, not routine data collection.

Terms of service and robots.txt

Before scraping a site, it's good practice to check its terms of service and robots.txt. These tell you what the site owner permits, and ignoring them can matter. That said, a site's ToS is a private agreement, not a law, so what it does and doesn't legally settle is genuinely nuanced and depends on where you're and what you're doing.

Public vs. gated data

A useful rule of thumb: scraping publicly available, non-authenticated data is generally viewed very differently from scraping content behind a login or paywall. Once you're authenticating into an account to reach data, you're typically agreeing to terms of use, and the picture changes considerably. Public pages that anyone can load without signing in sit on much safer ground than anything gated.

Rate limiting is just good manners

Independent of what Akamai enforces or what any policy requires, pacing your own requests is simply responsible. Hammering a site with rapid-fire requests can degrade its performance for real users, which is the kind of impact that turns a tolerated scraper into a targeted one. Slowing down protects the target, and it also keeps your own footprint low enough to avoid attention. For related guidance on scraping considerately, see our guide on scraping Google without getting blocked.

Final thoughts

Akamai is tough because it checks so many things at once: IP reputation, TLS fingerprints, browser and device signals, and behavioral patterns, all scored together to decide whether you're a real user. Getting past it means satisfying those layers rather than defeating them, which usually combines a TLS-impersonating client like curl_cffi, realistic headers, rotating residential IPs, and a real browser engine for the JavaScript checks.

None of it is a one-time build, since open source tools get flagged and Akamai's rules shift without warning, which is exactly why many teams eventually trade the maintenance treadmill for a managed solution like Decodo's Web Scraping API that absorbs every layer behind a single request. Whichever route you take, the smartest bypass is the one that collects public data responsibly and knows where the technical, ethical, and legal lines sit.