Akamai Bot Manager v2 Deep-Dive: Jak działa scoring i jak przejść go czysto w 2026

Akamai Bot Manager v2 Deep-Dive to dziś jedno z najczęściej wyszukiwanych haseł wśród inżynierów automatyzacji i badaczy bezpieczeństwa. Jeśli trafiłeś tutaj, prawdopodobnie próbujesz zrozumieć, dlaczego Twoje żądania dostają _abck z flagą ==-1, albo dlaczego sensor_data odrzuca sesję mimo poprawnego TLS. Ten artykuł rozkłada stos detekcji na części — od ciastek i telemetrii bmak, po sygnały post-quantum w Chrome 131+ — i pokazuje, jak legalna, autoryzowana automatyzacja przechodzi te kontrole czysto przy użyciu residential proxy ProxyHat.

Ważne zastrzeżenie prawne: Techniki opisane poniżej mają zastosowanie wyłącznie w autoryzowanym monitoringu własnych zasobów, testach penetracyjnych z wyraźną zgodą właściciela systemu oraz w badaniach bezpieczeństwa zgodnych z prawem. Omijanie zabezpieczeń bez autoryzacji może naruszać Computer Fraud and Abuse Act (CFAA) w USA oraz RODO/GDPR w Unii Europejskiej. ProxyHat nie wspiera ani nie toleruje oszustw, fałszowania tożsamości ani nieautoryzowanego skrapowania.

Akamai Bot Manager v2 Deep-Dive: Architektura scoringu w 2026

Akamai Bot Manager v2 nie jest prostym firewallem WAF, który blokuje na podstawie statycznej listy sygnatur. To system scoringowy uczący się maszynowo, który utrzymuje ciągły, serwerowy „trust score” dla każdej sesji. Wynik obliczany jest z kilkuset sygnałów zbieranych po stronie klienta (przeglądarki) i po stronie serwera (IP, ASN, nagłówki HTTP, TLS). Każde żądanie aktualizuje ten wynik, a decyzja o zablokowaniu lub wpuścieniu podejmowana jest dynamicznie — często dopiero po kilku żądaniach.

Kluczowe komponenty stosu detekcji:

• Ciastka _abck i ak_bmsc — tokeny sesyjne ustawiane przez Akamai, które kodują bieżący trust score.
• sensor.js / bmak — silnik telemetrii JavaScript, który zbiera dane behawioralne i sprzętowe, a następnie szyfruje je w polu sensor_data.
• Ciągły server-side trust score — model ML, który agreguje wszystkie sygnały i decyduje, czy sesja wygląda jak człowiek, czy jak bot.
• IP reputation i ASN scoring — waga reputacji adresu IP; datacenter ASN są z góry oznaczane jako bot.
• TLS i HTTP/2 fingerprinting — JA3/JA4 oraz ustawienia HTTP/2 SETTINGS muszą zgadzać się z deklarowanym User-Agent.

Rola ciastek _abck i ak_bmsc

Ciastko _abck to serce mechanizmu. Jest ustawiane przez odpowiedź serwera Akamai i zawiera zaszyfrowany trust score. Format wartości to ciąg znaków kończący się parą cyr, np. ~-1~-1~-1. Trzy końcowe liczby oznaczają status: 0 lub liczba dodatnia = sesja przeszła walidację; -1 = sesja wymaga jeszcze sensor_data; powtarzające się -1 = bot wykryty, sesja odrzucona.

Ciastko ak_bmsc to krótko-żyjące ciastko sesyjne (~24h), które działa jako wskaźnik „czy bmak został już załadowany”. Brak ak_bmsc oznacza, że silnik telemetrii jeszcze nie wystartował — co samo w sobie jest sygnałem bot.

Jak budowany jest sensor_data i dlaczego jedno pole psuje _abck

Silnik bmak (załadowany z sensor.js) zbiera setki punktów danych i kompresuje je do jednego zaszyfrowanego ciągu sensor_data, wysyłanego w żądaniu POST do /_bm/.... Jeśli którykolwiek z pól wewnątrz payloadu jest niespójny — np. rozdzielczość ekranu nie pasuje do User-Agent, albo brakuje zdarzeń myszy — Akamai natychmiast nadaje _abck status -1 i sesja jest trwale oznaczona jako bot.

Składowe sensor_data

Najczęstszy błąd scraperów: użycie biblioteki, która generuje sensor_data statycznie lub z zepsutym timingiem. Jeśli requestAnimationFrame ma jitter 0ms (brak jittera), albo zdarzenia myszy mają idealnie równe odstępy 50ms, Akamai wie, że to headless browser. Naturalny ruch ludzki ma nieregularny jitter — od 15ms do 20ms między klatkami, z okazjonalnymi piki powyżej 30ms.

2026: Sygnały protokołu — X25519MLKEM768, JA4 i HTTP/2

Od Chrome 131 (wydanego pod koniec 2024), Google domyślnie włączyło X25519MLKEM768 — hybrydowy post-quantum key share łączący X25519 z ML-KEM (dawniej Kyber). Oznacza to, że ClientHello przeglądarki Chrome 131+ zawiera wpis X25519MLKEM768 w rozszerzeniu key_share. Jeśli Twój scraping stack (np. starszy Python requests lub Node.js z OpenSSL 3.0) nie oferuje tego key share, Twój TLS fingerprint natychmiast zdradza, że nie jesteś prawdziwą przeglądarką Chrome — nawet jeśli User-Agent twierdzi inaczej.

Akamai Bot Manager v2 sprawdza zgodność trzech warstw:

1. JA4 TLS fingerprint — hash kolejności cipher suites, rozszerzeń i key shares. Chrome 131+ na Windows ma inny JA4 niż Firefox na Linux.
2. HTTP/2 SETTINGS frame — kolejność i wartości parametrów SETTINGS_HEADER_TABLE_SIZE, SETTINGS_MAX_CONCURRENT_STREAMS itd. Każda przeglądarka ma unikalny wzorzec.
3. User-Agent consistency — jeśli UA mówi „Chrome 131 na Windows 11”, ale JA4 wskazuje na OpenSSL/TLS-lib, sesja jest flagowana.

Narzędzia takie jak JA3 (Salesforce) i jego następca JA4 udostępniają publicznie bazy fingerprintów. Akamai idzie o krok dalej — porównuje nie tylko sam hash, ale też strukturę rozszerzeń i obecność post-quantum key share. Zgodnie z dokumentacją IETF draft-ietf-tls-hybrid-design, hybrydowy PQ key exchange jest teraz standardem w TLS 1.3, a główni dostawcy CDN (w tym Akamai) już go walidują.

Praktyczna konsekwencja

Nie możesz po prostu ustawić User-Agent: Mozilla/5.0 ... Chrome/131.0.0.0 w requests i liczyć na sukces. Musisz użyć przeglądarki (lub biblioteki, która wiernie emuluje pełny stos TLS + HTTP/2 + JS). Dlatego w 2026 większość poważnych zespołów scrapingowych używa Playwright/Puppeteer z stealth pluginami lub dedykowanych rozwiązań typu Camoufox/Browserforge, które generują spójne fingerprinty JA4 + HTTP/2 + canvas.

Dlaczego residential proxy są obowiązkowe: IP reputation i ASN scoring

Akamai Bot Manager v2 mocno obciąża reputację adresu IP. Datacenter ASN — np. OVH, Hetzner, DigitalOcean, AWS — są z góry klasyfikowane jako „bot infrastructure”. Trust score dla takiego IP startuje od razu niżej, a nawet perfekcyjny sensor_data może nie wystarczyć, by podnieść wynik powyżej progu.

Residential proxy, w przeciwieństwie do datacenter, korzystają z adresów IP przypisanych do realnych ISP (np. Comcast, Orange, Vodafone). Akamai widzi taki ruch jako „normalny użytkownik domowy” i trust score startuje wyżej. Mobile proxy (4G/5G) są jeszcze cenniejsze, bo operatory stosują CGNAT, co oznacza, że jeden adres IP jest współdzielony przez tysiące realnych urządzeń — niemożliwe do zbiorczego zablokowania bez collateral damage.

To właśnie dlatego akamai bot manager bypass w praktyce zawsze zaczyna się od wyboru właściwego typu proxy — a nie od samego kodu.

Praktyczna implementacja: ProxyHat residential + stealth browser

Poniższy przykład pokazuje, jak połączyć residential proxy ProxyHat z kontekstem przeglądarki Playwright, tak aby sensor_data i _abck były generowane poprawnie. Zakładamy, że pracujesz nad autoryzowanym monitoringiem lub badaniami bezpieczeństwa.

Krok 1: Konfiguracja proxy ProxyHat

ProxyHat residential proxy dostępne są przez gateway gate.proxyhat.com na porcie HTTP 8080 (lub SOCKS5 1080). Geo-targeting i sticky sessions konfiguruje się w nazwie użytkownika:

# HTTP proxy — residential, sticky session, USA
curl -x http://user-country-US-session-myresearch01:pass@gate.proxyhat.com:8080 https://example.com

# SOCKS5 proxy — residential, Germany, Berlin
curl -x socks5://user-country-DE-city-berlin-session-myresearch02:pass@gate.proxyhat.com:1080 https://example.com

Krok 2: Playwright z residential proxy i stealth context

from playwright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-myresearch01",
    "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",
    )

    # Inject stealth script to patch navigator.webdriver, etc.
    context.add_init_script("""
        Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
        Object.defineProperty(navigator, 'plugins', {
            get: () => [1, 2, 3, 4, 5],
        });
        window.chrome = { runtime: {} };
    """)

    page = context.new_page()
    page.goto("https://target-site.com", wait_until="networkidle")

    # Allow bmak to execute and mint _abck
    page.wait_for_timeout(3000)

    cookies = context.cookies()
    abck = next((c for c in cookies if c["name"] == "_abck"), None)
    print(f"_abck status: {abck['value'][-6:] if abck else 'MISSING'}")

    browser.close()

Kluczowe elementy, które sprawiają, że to działa:

• Real Chromium engine — generuje poprawny JA4 i HTTP/2 SETTINGS zgodny z UA Chrome 131.
• Residential IP — trust score nie startuje z „bot penalty”.
• Stealth init script — usuwa navigator.webdriver i inne oczywiste sygnały automatyzacji.
• Naturalny timing — wait_for_timeout(3000) pozwala bmak na zebranie zdarzeń i wysłanie sensor_data.

Krok 3: Weryfikacja _abck

Po wykonaniu sensor_data, sprawdź końcówkę wartości _abck:

• ~-1~-1~-1 — sensor_data jeszcze nie został przetworzony; wyślij kolejne żądanie.
• ~0~-1~-1 — sensor_data zaakceptowany, sesja przeszła walidację.
• ~-1~-1~2 lub podobne z dodatnią ostatnią cyfrą — bot wykryty, sesja odrzucona.

Najczęstsze błędy i przypadki brzegowe

1. Niezgodność TLS z User-Agent

Najczęstszy błąd: UA mówi „Chrome 131 na Windows”, ale TLS stack to Python ssl z OpenSSL 3.0, który nie oferuje X25519MLKEM768. Rozwiązanie: używaj Chromium przez Playwright/Puppeteer, albo biblioteki z konfigurowalnym TLS (np. cycletls w Go).

2. Sticky session zbyt długa

Jeśli używasz jednej sesji proxy przez 24h+, Akamai zauważy, że jeden „residential” IP wysyła tysiące żądań — to nienaturalne. Rotuj sesję co 500-1000 żądań lub co 30-60 minut.

3. Brak zdarzeń myszy/scroll

Headless browser bez interakcji generuje sensor_data z pustymi polami zdarzeń. Akamai traktuje to jako silny sygnał bota. Rozwiązanie: symuluj ruch myszy (page.mouse.move()) i scroll przed pierwszym żądaniem POST.

4. Canvas fingerprint collision

Jeśli wiele sesji używa tego samego obrazu canvas fingerprint (bo korzystają z identycznego obrazu Docker), Akamai grupuje je jako jednego operatora. Rozwiązanie: losuj parametry canvas (np. --use-gl=angle --use-angle=swiftshader z różnymi seedami) lub używaj Browserforge do generowania unikalnych fingerprintów.

5. HTTP/2 SETTINGS mismatch

Nawet przy poprawnym JA4, jeśli kolejność parametrów HTTP/2 SETTINGS nie pasuje do deklarowanej przeglądarki, Akamai odrzuci sesję. Biblioteki takie jak curl-impersonate rozwiązują ten problem, kopiując dokładne ramki HTTP/2 z konkretnych wersji przeglądarek.

Kiedy to jest odpowiednie — a kiedy nie

Techniki omijania Akamai Bot Manager v2 są uzasadnione w następujących scenariuszach:

• Autoryzowany monitoring własnych usług — np. sprawdzanie dostępności Twojego serwisu przez zewnętrzne narzędzie.
• Testy penetracyjne — z wyraźną, pisemną zgodą właściciela systemu.
• Badania bezpieczeństwa — analiza mechanizmów detekcji w celach akademickich lub bug bounty.
• Legalny web scraping — pobieranie publicznie dostępnych danych zgodnie z robots.txt i warunkami serwisu.

Nie są uzasadnione: fałszowanie transakcji, omijanie limitów zakupowych (sneaker/ticketing botting), ataki credential stuffing, czy jakakolwiek aktywność naruszająca CFAA, RODO/GDPR lub warunki serwisu. Więcej informacji znajdziesz w dokumentacji ProxyHat oraz na stronie cennika ProxyHat.

Kluczowe wnioski

• _abck to ciągły trust score, nie binarny allow/deny. Status ~-1~-1~-1 oznacza „czeka na sensor_data”, nie „zablokowany”.
• sensor_data musi być spójny — jedno niezgodne pole (ekran, GPU, timing) unieważnia całą sesję.
• Chrome 131+ wymaga X25519MLKEM768 w TLS ClientHello; bez tego JA4 zdradza bot.
• Residential proxy są obowiązkowe — datacenter ASN są pre-scored jako bot i trust score startuje zbyt nisko.
• Rotuj sesje co 500-1000 żądań, aby uniknąć wykrycia wzorca „jeden IP, tysiące żądań”.
• Używaj real Chromium przez Playwright/Puppeteer — nie requests z fałszywym UA.

Jeśli chcesz zobaczyć, jak ProxyHat residential proxy sprawdzają się w Twoim przypadku, przejdź do listy lokalizacji lub odwiedź stronę web scraping i SERP tracking.