Akamai Bot Manager v2 — głęboka analiza: jak działa wykrywanie botów w 2026 roku

Akamai Bot Manager v2 — głęboka analiza: zarys problemu

Akamai Bot Manager v2 to w 2026 roku jeden z najbardziej zaawansowanych systemów wykrywania automatyzacji na rynku. Jeśli kiedykolwiek próbowałeś autoryzowane scrapowanie, monitorowanie cen lub testy penetracyjne i nagle otrzymałeś HTTP 403 po kilkudziesięciu żądaniach — prawdopodobnie natknąłeś się właśnie na niego. W tej głębokiej analizie Akamai Bot Manager v2 rozkładamy na czynniki pierwsze pełen stos sygnałów: od ciasteczka _abck, przez telemetrię sensor.js, po fingerprinty TLS JA4 i post-quantum key share X25519MLKEM768, które są teraz domyślne w Chrome 131+.

Ważne zastrzeżenie prawne: informacje w tym artykule są przeznaczone wyłącznie do celów autoryzowanego monitorowania, badań bezpieczeństwa, testów penetracyjnych za zgodą właściciela systemu oraz zgodnej z prawem automatyzacji. Omijanie mechanizmów ochrony bez autoryzacji może naruszać Computer Fraud and Abuse Act (CFAA) w USA, GDPR w UE oraz regulaminy dostawców usług. Przestrzegaj robots.txt, warunków serwisu i lokalnych przepisów.

Dlaczego ten problem istnieje: kontekst techniczny

Akamai Bot Manager v2 nie polega na pojedynczym teście. To ciągły, serwerowy system scoringowy, który ocenia każde żądanie w czasie rzeczywistym, aktualizując poziom zaufania na podstawie setek sygnałów. W przeciwieństwie do prostych rozwiązań WAF, które blokują na podstawie statycznych reguł, Bot Manager v2 utrzymuje płynny wynik zaufania dla każdej sesji — i ten wynik może się pogorszyć w każdej chwili, jeśli kolejne żądanie nie pasuje do wcześniejszego profilu behawioralnego.

System składa się z trzech głównych warstw:

• Warstwa sieciowa — reputacja IP, ASN, geolokalizacja, typ połączenia (residential vs datacenter).
• Warstwa protokołu — fingerprint TLS (JA3/JA4), fingerprint HTTP/2 SETTINGS, zgodność z deklarowanym User-Agent.
• Warstwa behawioralna — telemetria zebrana przez sensor.js (alias bmak), obejmująca ruch myszy, scroll, dotyk, właściwości ekranu/GPU i timing.

Każda warstwa jest konieczna, ale żadna nie jest wystarczająca. Możesz mieć idealny fingerprint TLS, ale jeśli Twój ruch pochodzi z datacenter ASN OVH (AS16276) lub AWS (AS16509), system wstępnie oznaczy Cię jako bota z wysokim prawdopodobieństwem. Z drugiej strony, residential IP bez poprawnego sensor_data również zostanie odrzucone. Kluczem jest spójność całego stosu.

Stos sygnałów: ciasteczka _abck i ak_bmsc

Sercem mechanizmu są dwa ciasteczka: _abck i ak_bmsc. Zrozumienie ich cyklu życia jest fundamentalne dla każdego, kto zajmuje się akamai bot detection 2026.

Ciasteczko ak_bmsc — token sesji początkowej

ak_bmsc to ciasteczko ustawiane przez serwer Akamai przy pierwszym żądaniu HTTP, zanim jakikolwiek JavaScript zostanie wykonany. Służy jako identyfikator sesji dla warstwy sieciowej i jest powiązany z Twoim adresem IP, fingerprintem TLS i nagłówkami HTTP. Jeśli zmienisz IP mid-sesji bez zachowania ak_bmsc, system zinterpretuje to jako anomalię.

Ciasteczko _abck — ciągły wynik zaufania

_abck to ciasteczko, które jest aktualizowane wielokrotnie podczas sesji. Jego wartość zawiera zakodowany wynik zaufania i jest odnawiana po każdym żądaniu, które przechodzi przez weryfikację sensor.js. Struktura _abck wygląda mniej więcej tak:

_abck=8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F8F~-1~-1~-1

Po znaku ~ następują trzy liczby całkowite, które wskazują stan weryfikacji:

• -1 — sesja nie została jeszcze zweryfikowana (sensor_data nie został wysłany lub jest nieprawidłowy).
• 0 — sesja przeszła weryfikację behawioralną, ale jest monitorowana.
• 1 — sesja została oznaczona jako bot.

Częstym błędem jest założenie, że raz zdobyte _abck z wartością ~0~-1~-1 wystarczy na całą sesję. W Bot Manager v2 system okresowo wymaga odświeżenia — zazwyczaj co 5–10 minut lub po określonej liczbie żądań. Jeśli nie wyślesz nowego, poprawnego sensor_data, wynik zaufania spadnie.

Kluczowa zasada: _abck to nie bilet jednorazowy. To dynamiczny scoring, który musi być stale podtrzymywany poprawną telemetrią.

Sensor_data Akamai: jak bmak buduje telemetrię

Skrypt sensor.js, znany również pod wewnętrznym aliasem bmak, jest sercem warstwy behawioralnej. Jest to silnie zaciemniony moduł JavaScript, który zbiera dziesiątki sygnałów i kompresuje je w pojedynczy ciąg znaków zwany sensor_data. Ten ładunek jest wysyłany jako parametr POST do endpointu Akamai (zazwyczaj /_bm/... lub podobnego) i jest podstawą odnawiania _abck.

Składowe sensor_data

Ładunek sensor_data składa się z następujących kategorii sygnałów:

Kategoria	Przykładowe sygnały	Waga scoringowa
Urządzenie wejściowe	Ruch myszy (x, y, timestamp), scroll velocity, touch events, keypress timing	Wysoka
Ekran i GPU	screen.width, screen.height, devicePixelRatio, WebGL renderer, WebGL vendor, canvas fingerprint hash	Wysoka
Timing	performance.now() deltas, requestAnimationFrame cadence, event loop latency	Średnia
Środowisko JS	navigator.platform, navigator.languages, navigator.hardwareConcurrency, navigator.deviceMemory, timezone offset	Średnia
Protokół (pośrednio)	User-Agent consistency checks, Sec-CH-UA client hints alignment	Wysoka

Dlaczego pojedyncze nieścisłość natychmiast unieważnia _abck? Bot Manager v2 używa modelu krzyżowej walidacji. Jeśli sensor_data deklaruje navigator.platform = "Win32", ale User-Agent twierdzi, że jesteś na Linux, system oznacza to jako sprzeczność. Jeśli WebGL renderer mówi ANGLE (NVIDIA, NVIDIA GeForce RTX 4070 Direct3D11 vs_5_0 ps_5_0), ale navigator.hardwareConcurrency wynosi 2, a deviceMemory to 2 GB — to jest nierealistyczna kombinacja dla desktopu z RTX 4070.

Każda taka nieścisłość obniża wynik zaufania. Dwie lub trzy wystarczą, aby _abck zostało zaktualizowane do ~1~-1~-1, co oznacza flagę bota. Co gorsza, flaga jest trwała dla tej sesji — nie możesz jej cofnąć wysłaniem poprawnego sensor_data później. Musisz zacząć nową sesję z nowym IP.

Wyzwania z emulacją sensor_data

Niektóre zespoły próbują generować sensor_data ręcznie, bez uruchamiania prawdziwej przeglądarki. To podejście jest niezwykle trudne w 2026 roku, ponieważ:

1. Skrypt bmak jest regularnie aktualizowany (często co 2–4 tygodnie), zmieniając format ładunku i algorytmy obfuskacji.
2. Telemetria wejścia musi być statystycznie realistyczna — ruch myszy musi mieć naturalne krzywe Béziera, prędkość scrolla musi pasować do rozdzielczości ekranu, a przerwy między zdarzeniami muszą mieć rozkład zbliżony do ludzkiego.
3. Fingerprinty WebGL i canvas muszą być wewnętrznie spójne i pasować do deklarowanego User-Agent.

Dlatego w praktyce najskuteczniejszym podejściem dla legalnej automatyzacji jest użycie prawdziwej przeglądarki ze stealth context (np. Playwright + patchright lub Puppeteer + stealth plugin) przez residential proxy, tak aby sensor.js mógł naturalnie zebrać i wysłać poprawne sensor_data.

Sygnały protokołu 2026: JA4, HTTP/2 i post-quantum X25519MLKEM768

W 2026 roku fingerprinty protokołu są równie ważne co telemetria JavaScript. Akamai Bot Manager v2 krzyżuje te sygnały z deklarowanym User-Agent, a niezgodność jest natychmiast karana.

JA4 TLS fingerprint

JA4 to ulepszony następca JA3, opracowany przez FoxIO i zintegrowany z wieloma systemami wykrywania. W przeciwieństwie do JA3, JA4 jest formatowalny i porównywalny — dzieli fingerprint na cztery sekcje rozdzielone podkreślnikami:

JA4 = t13d1516h2_8daaf6152771_b186095e22b6
       ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
       TLS extensions   cipher suites    ALPN + extensions hash

Akamai utrzymuje bazę znanych fingerprintów JA4 dla każdej kombinacji przeglądarka-wersja-system operacyjny. Jeśli Twój User-Agent twierdzi, że jesteś Chrome 131 na Windows 11, ale Twój JA4 pasuje do Python requests z biblioteką urllib3, system odrzuci żądanie niezależnie od poprawności _abck.

Według dokumentacji FoxIO, JA4 zapewnia stabilność między wersjami i pozwala na precyzyjne rozróżnienie przeglądarek — co jest jednocześnie błogosławieństwem dla obrońców i wyzwaniem dla automatyzacji.

HTTP/2 SETTINGS fingerprint

Oprócz TLS, Bot Manager v2 analizuje ramkę SETTINGS w protokole HTTP/2. Każdy klient wysyła różne wartości parametrów takich jak HEADER_TABLE_SIZE, ENABLE_PUSH, INITIAL_WINDOW_SIZE i MAX_CONCURRENT_STREAMS. Kolejność i wartości tych parametrów tworzą unikalny fingerprint, który Akamai porównuje z bazą.

Na przykład Chrome 131 wysyła ramkę SETTINGS z określoną kolejnością i wartościami, podczas gdy httpx w Python lub axios w Node.js mają zupełnie inne fingerprinty. Biblioteka tls-client próbuje emulować te fingerprinty, ale wymaga ciągłej aktualizacji.

X25519MLKEM768 — post-quantum key share w Chrome 131+

Od Chrome 131 (wydanego w listopadzie 2024 roku), Google domyślnie włączyło hybrydowy post-quantum key share X25519MLKEM768 (wcześniej znany jako X25519Kyber768) w TLS 1.3. Oznacza to, że fingerprint JA4 dla Chrome 131+ zawiera identyfikator grupy x25519mlkem768 w sekcji rozszerzeń TLS.

To ma ogromne znaczenie dla Bot Manager v2: jeśli Twój User-Agent twierdzi, że jesteś Chrome 131+, ale Twój klient TLS nie wysyła X25519MLKEM768 w ClientHello, Akamai wie, że nie używasz prawdziwego Chrome. Większość bibliotek HTTP (Python requests, httpx, Node.js undici) nie obsługuje tego key share, ponieważ opiera się na bibliotece BoringSSL używanej przez Chrome.

To jest powód, dla którego w 2026 roku emulacja fingerprintu TLS jest praktycznie niemożliwa bez użycia prawdziwej przeglądarki lub bardzo zaawansowanych bibliotek takich jak curl-impersonate w wersji obsługującej Chrome 131+. Najbezpieczniejszym wyborem pozostaje headless Chrome lub Chromium uruchomiony przez Playwright/Puppeteer.

Dlaczego residential proxy są konieczne

Nawet z idealnym fingerprintem TLS i poprawnym sensor_data, bez odpowiedniego adresu IP Twoja automatyzacja zostanie odrzucona. Bot Manager v2 silnie waży reputację IP i klasyfikuje adresy na podstawie ASN, typu połączenia i historycznego zachowania.

Datacenter ASN są pre-scoringowane jako bot

Akamai utrzymuje listę ASN należących do dostawców chmurowych i centrów danych. Adresy z tych zakresów otrzymują początkowy wynik zaufania bliski zero. Przykłady pre-flagowanych ASN:

ASN	Dostawca	Domyślny scoring Akamai
AS16509	Amazon AWS	Bot (wysokie prawdopodobieństwo)
AS14618	Amazon AWS (us-east-1)	Bot (wysokie prawdopodobieństwo)
AS8075	Microsoft Azure	Bot (wysokie prawdopodobieństwo)
AS16276	OVH	Bot (wysokie prawdopodobieństwo)
AS14061	DigitalOcean	Bot (wysokie prawdopodobieństwo)
AS7979	Comcast (residential)	Human (domyślnie zaufany)
AS3320	Deutsche Telekom (residential)	Human (domyślnie zaufany)

To nie znaczy, że datacenter IP zawsze są blokowane — niektóre endpointy API mają łagodniejsze reguły. Ale dla stron chronionych pełnym Bot Manager v2, datacenter proxy skutecznie uniemożliwiają zdobycie poprawnego _abck z wynikiem ~0~-1~-1.

Mobile proxy jako alternatywa

Mobile proxy (adresy z ASN operatorów komórkowych takich jak T-Mobile, Verizon, Vodafone) mają bardzo wysoką reputację, ponieważ są niemożliwe do odróżnienia od ruchu prawdziwych urządzeń mobilnych. Mają jednak wyższą latencję (często 100–300ms vs 20–50ms dla residential) i mniejszą pulę adresów.

Dla Akamai Bot Manager v2, residential proxy są optymalnym kompromisem między reputacją IP, latencją i dostępnością geograficzną.

Praktyczna implementacja: ProxyHat + stealth browser

Poniżej znajduje się kompletny, działający przykład legalnej automatyzacji przez Akamai Bot Manager v2, używający ProxyHat residential proxy i Playwright z Chromium. Podejście polega na pozwoleniu prawdziwej przeglądarce na naturalne wygenerowanie sensor_data i _abck, zamiast próby ręcznej emulacji.

Krok 1: Konfiguracja ProxyHat residential proxy

ProxyHat używa formatu uwierzytelniania w nazwie użytkownika. Aby ustawić kraj (np. US) i sticky session:

# HTTP proxy
http://user-country-US-session-myauth01:pass@gate.proxyhat.com:8080

# SOCKS5 proxy
socks5://user-country-US-session-myauth01:pass@gate.proxyhat.com:1080

Pełną dokumentację parametrów geo-targeting i sesji znajdziesz na docs.proxyhat.com. Dostępne lokalizacje sprawdzisz na stronie lokalizacji ProxyHat.

Krok 2: Playwright z residential proxy

from playwright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-myauth01",
    "password": "pass"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy=PROXY,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
        ]
    )
    context = browser.new_context(
        user_agent=(
            "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
            "AppleWebKit/537.36 (KHTML, like Gecko) "
            "Chrome/131.0.0.0 Safari/537.36"
        ),
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
    )

    page = context.new_page()

    # Wstrzykuj stealth script przed załadowaniem strony,
    # aby ukryć navigator.webdriver i inne sygnały automatyzacji
    context.add_init_script("""
        Object.defineProperty(navigator, 'webdriver', {
            get: () => undefined
        });
        Object.defineProperty(navigator, 'plugins', {
            get: () => [1, 2, 3, 4, 5]
        });
        Object.defineProperty(navigator, 'languages', {
            get: () => ['en-US', 'en']
        });
    """)

    page.goto("https://example-protected-site.com", wait_until="networkidle")

    # Poczekaj na _abck cookie — sensor.js musi wykonać się
    # i wysłać sensor_data. Zazwyczaj trwa to 2–5 sekund.
    page.wait_for_timeout(5000)

    cookies = context.cookies()
    abck = next((c for c in cookies if c["name"] == "_abck"), None)
    if abck:
        print(f"_abck value: {abck['value'][:40]}...")
        # Sprawdź czy ~0~-1~-1 (zweryfikowana) czy ~-1~-1~-1 (niezweryfikowana)
        if "~0~-1~-1" in abck["value"]:
            print("Sesja zweryfikowana pomyślnie!")
        else:
            print("Sesja niezweryfikowana — sprawdź sensor_data")

    # Pobierz treść strony
    content = page.content()
    print(f"Długość treści: {len(content)} znaków")

    browser.close()

Krok 3: Utrzymanie sesji i rotacja

Dla długich sesji scrapingu, musisz utrzymać ten sam adres IP (sticky session) przez cały czas trwania sesji, aby _abck i ak_bmsc pozostały ważne. Jeśli zmienisz IP, ciasteczka zostaną unieważnione i musisz zacząć od nowa.

ProxyHat obsługuje sticky sessions przez flagę session- w nazwie użytkownika:

# Sticky session — ten sam IP przez całą sesję
http://user-country-US-session-persistent01:pass@gate.proxyhat.com:8080

# Rotacja per-request — nowy IP przy każdym żądaniu
http://user-country-US:pass@gate.proxyhat.com:8080

Do monitorowania cen lub śledzenia SERP, gdzie każde żądanie jest niezależne, rotacja per-request jest odpowiednia. Do ciągłych sesji interaktywnych (jak przykład wyżej), sticky session jest konieczna.

Krok 4: curl z poprawnym fingerprintem (dla prostych żądań)

Dla żądań, które nie wymagają pełnej przeglądarki (np. API endpointy z łagodniejszą ochroną), możesz użyć curl z ProxyHat:

curl -x http://user-country-US-session-sess01:pass@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" \
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "Accept-Language: en-US,en;q=0.9" \
  -H "Sec-CH-UA: \"Chromium\";v=\"131\", \"Not_A Brand\";v=\"24\"" \
  -H "Sec-CH-UA-Mobile: ?0" \
  -H "Sec-CH-UA-Platform: \"Windows\"" \
  --compressed \
  "https://example-protected-site.com/api/data"

Uwaga: standardowy curl nie wysyła X25519MLKEM768 key share, więc JA4 fingerprint nie będzie pasował do Chrome 131. Dla stron z pełnym Bot Manager v2, użyj curl-impersonate-chrome131 lub Playwright.

Najczęstsze błędy i przypadki brzegowe

1. Niezgodność Sec-CH-UA z User-Agent

Chrome 131+ wysyła nagłówki Sec-CH-UA (Client Hints). Jeśli wysyłasz User-Agent: Chrome/131, ale nie wysyłasz Sec-CH-UA, Akamai wie, że to nie prawdziwy Chrome. Wartości Sec-CH-UA muszą być dokładnie zgodne z wersją w User-Agent.

2. Zmiana IP mid-sesji

Najczęstszy błąd: rotacja IP w trakcie aktywnej sesji. _abck jest powiązane z IP, z którym zostało wygenerowane. Zmiana IP powoduje natychmiastowe unieważnienie. Używaj sticky session dla całej sesji przeglądarki.

3. Brak ruchu myszy w headless mode

Headless Chrome bez ruchu myszy generuje sensor_data z pustymi tablicami zdarzeń wejścia. Bot Manager v2 traktuje to jako silny sygnał bota. Rozwiązanie: użyj page.mouse.move() z losowymi współrzędnymi przed i podczas nawigacji, albo użyj biblioteki takiej jak ghost-cursor dla realistycznych krzywych ruchu.

4. WebGL fingerprint z headless

Headless Chromium na serwerze Linux bez GPU raportuje WebGL renderer: SwiftShader lub Google SwiftShader. To jest natychmiast rozpoznawane jako środowisko headless. Rozwiązania:

• Użyj --use-gl=angle --use-angle=swiftshader z maskowaniem WebGL przez stealth plugin.
• Użyj Xvfb z wirtualnym framebuffer i GPU passthrough.
• Wstrzyknij fałszywy getParameter dla WebGLRenderingContext, zwracający realistyczny renderer pasujący do User-Agent.

5. Zbyt wysoka częstotliwość żądań

Nawet z poprawnym _abck, Bot Manager v2 monitoruje wzorzec żądań. 1500 żądań na sekundę z jednej sesji jest nieludzkie. Utrzymuj realistyczne tempo: 1–5 żądań na sekundę na sesję, z losowymi przerwami 200–800ms.

Kiedy to podejście jest odpowiednie

Techniki opisane w tym artykule są odpowiednie wyłącznie dla:

• Autoryzowanego monitorowania — śledzenie cen własnych produktów, monitorowanie dostępności usług, dla których masz zgodę.
• Badań bezpieczeństwa — testy penetracyjne z pisemną autoryzacją właściciela systemu.
• Legalnej automatyzacji — interakcje z API i serwisami zgodnie z ich warunkami serwisu.
• Web scrapingu danych publicznych, z poszanowaniem robots.txt i limitów.

To NIGDY nie jest odpowiednie dla: oszustw, kradzieży danych, omijania płatności, masowego kupowania biletów/sneakerów wbrew regulaminom, ani jakiejkolwiek działalności naruszającej CFAA, GDPR lub regulaminy serwisów.

Kluczowe wnioski

• _abck to dynamiczny, ciągły scoring — nie bilet jednorazowy. Musi być stale podtrzymywany poprawnym sensor_data.
• sensor_data musi być wewnętrznie spójna: ekran, GPU, platforma, timing i ruch wejścia muszą pasować do siebie nawzajem i do User-Agent.
• W 2026 roku fingerprint TLS JA4 musi zawierać X25519MLKEM768 dla Chrome 131+ — biblioteki HTTP tego nie obsługują, więc prawdziwa przeglądarka jest konieczna.
• Datacenter ASN są pre-scoringowane jako bot. Residential proxy z dobrym ASN są warunkiem koniecznym.
• Najskuteczniejsze podejście: prawdziwa przeglądarka (Playwright/Puppeteer) + residential proxy (ProxyHat) + stealth context, pozwalające sensor.js na naturalne działanie.
• Sticky session jest konieczna dla utrzymania _abck — zmiana IP mid-sesji unieważnia ciasteczka.
• Przestrzegaj CFAA, GDPR, robots.txt i warunków serwisu. Legalna automatyzacja to jedyna odpowiednia forma użycia tych technik.

Sprawdź ceny ProxyHat aby znaleźć plan residential proxy odpowiedni dla Twojego przypadku użycia, lub przejdź do dokumentacji aby poznać pełną listę parametrów geo-targeting i sesji.