Akamai Bot Manager v2 Derin İnceleme: 2026'da Tespit Nasıl Çalışır ve Yasal Otomasyon Nasıl Geçer?

Akamai Bot Manager v2, 2026 itibarıyla web otomasyonunun en zorlu rakiplerinden biri. Bu rehberde Akamai Bot Manager v2 Derin İnceleme (Deep-Dive) bağlamında sistemin nasıl puanladığını, _abck cookie'sinin nasıl üretildiğini ve sensor_data payload'unun neden tek bir alan uyumsuzluğunda çöktüğünü inceleyeceğiz. Amaç, sahtekarlık değil; yetkili güvenlik araştırması, fiyat izleme ve SERP takibi yapan mühendislerin sistemi temiz ve yasal biçimde aşabilmesidir.

Yasal Uyarı: Bu içerik, ABD Bilgisayar Dolandırıcılığı ve Kötüye Kullanım Yasası (CFAA) ve GDPR kapsamında yetkili güvenlik testleri, izinli veri toplama ve kendi siteniz/kullanıcılarınız için yapılan otomasyon bağlamında hazırlanmıştır. Hedef sitenin robots.txt ve Hizmet Şartları'nı kontrol edin; izinsiz erişim yasa dışıdır. ProxyHat, sahtekarlık, kredi kartı testi veya hesap ele geçirmek için kullanılamaz.

Akamai Bot Manager v2 Derin İnceleme: Sistem Neden Bu Kadar Zor?

Akamai Bot Manager v2, tek bir sinyale güvenmez. Bunun yerine, istemci tarafı telemetry, sunucu tarafı itibar skoru ve TLS/HTTP/2 katmanı parmak izlerini birleştiren bir sürekli güven skoru modeli kullanır. Bu, 2010'ların basit User-Agent filtrelerinden farklı olarak, her istekte cookie'leri yeniden doğrular ve tek bir tutarsuzlukta tüm oturumu geçersiz kılar.

Sistem üç temel katmandan oluşur:

• Cookie katmanı: _abck (JWT benzeri imzalı güven token'ı) ve ak_bmsc (ilk ziyaret oturum cookie'si).
• Telemetry katmanı: sensor.js / bmak motoru tarafından toplanan davranışsal ve cihaz sinyalleri, base64 ile kodlanmış sensor_data payload'una paketlenir.
• Sunucu tarafı skor katmanı: IP ASN itibarı, coğrafi tutarlılık, istek hızı ve geçmiş davranış ile birleşen sürekli bir güven skoru.

Bu üç katman birbirini doğrular. _abck cookie'si geçerli görünse bile, sunucu tarafı skor düşükse veya TLS parmak izi tutarsızsa, Akamai sessizce bm_sz challenge'ı tetikler veya doğrudan 403 döndürür. 2026'da bu, Akamai'nin resmi Bot Manager belgelerinde de vurgulanan "zero-trust bot detection" yaklaşımıdır.

_abck ve ak_bmsc Cookie'leri: İmza Mekanizması

ak_bmsc, ilk sayfa yüklemede sunucu tarafından set edilen kısa ömürlü bir oturum cookie'sidir. Amacı, istemcinin sensor.js'i çalıştırıp çalıştırmadığını doğrulamaktır. _abck ise asıl güven token'ıdır ve yaklaşık 7 gün geçerli kalır; ancak bu süre boyunca her istekte yeniden değerlendirilir.

_abck'nin kritik özelliği, içindeki bm_ alanlarının sensor_data payload'undaki değerlerle eşleşmesi gerektiğidir. Eğer sensor_data içindeki ekran çözünürlüğü, GPU satıcı kimliği veya fare hareketi histogramı, _abck'nin ilk üretildiği andaki değerlerle uyuşmazsa, sunucu token'ı geçersiz kılar ve yeni bir challenge döngüsü başlatır.

Bu, RFC 6265 (HTTP State Management) cookie semantiğinin ötesinde, uygulama katmanı imzasıdır. Basit cookie kopyalama veya manuel header spoofing çalışmaz; çünkü imza, runtime'da toplanan telemetry ile kriptografik olarak bağlanmıştır.

sensor_data Payload'u: bmak Telemetry Motoru

sensor.js, genellikle _bm/_akamai yolundan yüklenen obfuscate edilmiş bir JavaScript motorudur. İçindeki bmak nesnesi, aşağıdaki sinyalleri toplar ve birleştirir:

• Fare/scroll/dokunma olayları: Her mousemove, scroll, touchstart olayının zaman damgası, koordinatları ve hızı. Bu, doğal insan davranışının gürültülü histogramını oluşturur; lineer veya tamamen rastgele hareketler bot olarak işaretlenir.
• Ekran ve GPU özellikleri: navigator.hardwareConcurrency, screen.colorDepth, WebGLRenderingContext.getParameter(0x9245) (UNMASKED_VENDOR_WEBGL) ve GPU renderer dizesi.
• Zamanlama: performance.now() çözünürlüğü, setInterval jitter'ı, requestAnimationFrame kadansı.
• Tarayıcı tutarlılığı: navigator.webdriver, navigator.plugins, navigator.languages ve User-Agent ile tutarlılık.

Bu sinyaller, bmak.sensor_data alanında birleştirilir ve genellikle bir POST isteğiyle Akamai'ye gönderilir. Payload, perde arkasında bir dizi checksum ve HMAC içerir; bu nedenle tek bir alanı değiştirmek tüm imzayı bozar. Örneğin, User-Agent'da Chrome/131 iddia ederken navigator.webdriver true döndürmek, anında _abck geçersizleştirmesine yol açar.

Bu, MDN WebGL belgelerinde açıklanan standart API'lerin kötüye kullanımına dayalı bir parmak izidir. Stealth tarayıcılar, bu API'leri gerçek bir tarayıcı bağlamında çalıştırarak geçer; sahte değerler enjekte etmez.

2026 Protokol Sinyalleri: X25519MLKEM768 ve JA4

2026'da Akamai, TLS katmanında daha agresif parmak izleme yapıyor. Chrome 131+'da varsayılan olan X25519MLKEM768 post-quantum key share'i, ClientHello'da yeni bir eğri grubu (0x11EC) tanıtır. Eğer User-Agent Chrome 131+ iddia ediyorsa ama ClientHello'da bu key share yoksa, Akamai bunu açık bir tutarsızlık olarak işaretler.

JA4 fingerprint'i, TLS ClientHello'daki cipher suite sıralamasını, uzantı sıralamasını ve ALPN değerlerini birleştirerek üretılır. Örneğin, gerçek Chrome 131'in JA4 hash'i t13d1516h2_8daaf6152771_b186095e22b6 formatında belirgin bir imzadır. Python requests veya standart urllib3 bu imzayı üretemez; çünkü TLS stack'i BoringSSL değil, OpenSSL kullanır ve cipher sıralaması farklıdır.

HTTP/2 katmanında da SETTINGS çerçevesi parmak izi alınır: HEADER_TABLE_SIZE, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS değerlerinin sıralaması ve varlığı tarayıcıya özeldir. Chrome, Firefox ve Safari farklı SETTINGS imzaları üretir; bu nedenle User-Agent ile HTTP/2 SETTINGS çerçevesi uyuşmazsa, Akamai bunu bot olarak puanlar.

Bu parmak izleri, RFC 9325 (TLS Best Current Practices) ve IETF TLS çalışma grubu taslaklarında tartışılan standart TLS davranışından sapmaları yakalar. Pratikte, bu sinyalleri geçmenin tek yolu, gerçek bir tarayıcı motoru (Chromium veya Firefox) kullanmaktır; saf HTTP istemcileri yeterli değildir.

Neden Veri Merkezi Proxy'leri Başarısız Olur: IP İtibar Ağırlığı

Akamai Bot Manager v2, IP ASN itibarını ağır biçimde ağırlıklandırır. AWS, Google Cloud, Azure, DigitalOcean ve OVH gibi veri merkezi ASN'leri, başlangıçta bot olarak önceden puanlanır. Bu, _abck cookie'si mükemmel olsa bile, IP skoru düşük olduğu için challenge tetiklenebileceği anlamına gelir.

Buna karşın, gerçek ISP ASN'lerine ait residential IP'ler (örneğin Türk Telekom, Comcast, Vodafone Germany) yüksek başlangıç skoru alır. Bu nedenle, akamai bot manager bypass bağlamında residential proxy'ler zorunludur; datacenter proxy'ler 2026'da neredeyse her zaman ilk 50 istekte yakalanır.

Mobile proxy'ler de güçlü bir seçenektir; doğal IP rotasyonu ve yüksek ASN itibarı nedeniyle Akamai tarafından genellikle gerçek mobil kullanıcı olarak sınıflandırılır. Ancak residential proxy'ler, daha tutarlı coğrafi hedefleme ve daha uzun sticky session süreleri sunar.

Yasal Yaklaşım: ProxyHat ile Stealth Tarayıcı Bağlamı

Akamai Bot Manager v2'yi yasal biçimde aşmak için üç bileşen gerekir: gerçek bir tarayıcı motoru, tutarlı TLS/HTTP/2 parmak izi ve yüksek itibarlı residential IP. Aşağıdaki örnek, ProxyHat residential proxy'leri ile Playwright (Chromium) kullanarak sensor_data ve _abck'nin doğru üretilmesini sağlar.

1. ProxyHat Residential Proxy Bağlantısı

ProxyHat gateway'i, HTTP için gate.proxyhat.com:8080, SOCKS5 için gate.proxyhat.com:1080 kullanır. Username içinde ülke ve şehir hedeflemesi yapılabilir:

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

# HTTP proxy - Almanya, Berlin
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080

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

# Sticky session (aynı IP'yi koru)
http://user-session-abc123-country-US:pass@gate.proxyhat.com:8080

2. Playwright ile Stealth Tarayıcı Kurulumu

from playwright.sync_api import sync_playwright

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

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # headless=True bazı sitelerde tespit edilir
        proxy=PROXY,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
            "--disable-dev-shm-usage"
        ]
    )
    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
        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"
        )
    )
    page = context.new_page()
    page.goto("https://example.com", wait_until="networkidle")
    
    # _abck cookie'sinin yerleşmesini bekle
    page.wait_for_timeout(3000)
    cookies = context.cookies()
    abck = [c for c in cookies if c["name"] == "_abck"]
    print(f"_abck present: {len(abck) > 0}")
    
    browser.close()

Bu yaklaşımda kritik noktalar:

• headless=False veya Xvfb ile gerçek bir ekran bağlamı kullanın; saf headless modu bazı bmak kontrollerinde yakalanır.
• Viewport, locale ve timezone, User-Agent ile tutarlı olmalıdır. ABD IP'si ile Europe/Berlin timezone kullanmak anında tespit edilir.
• Sticky session kullanın; her istekte IP değiştirmek, _abck'nin imza doğrulamasını bozar.

3. curl ile Hızlı Test

# ProxyHat üzerinden basit HTTP testi
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/131.0.0.0 Safari/537.36" \
  -c cookies.txt \
  https://example.com/

# Cookie'leri kontrol et
grep -E "_abck|ak_bmsc" cookies.txt

curl tek başına Akamai'yi geçemez (TLS parmak izi yanlış), ancak cookie akışını ve proxy bağlantısını doğrulamak için kullanışlıdır.

Yaygın Hatalar ve Edge Case'ler

Hata 1: User-Agent ile TLS Parmak İzi Uyuşmazlığı

En sık yapılan hata, Python requests ile Chrome User-Agent kullanmaktır. requests, OpenSSL TLS stack'i kullanır; JA4 hash'i Chrome'un BoringSSL imzasından farklıdır. Akamai bunu anında yakalar. Çözüm: Playwright, Puppeteer veya Selenium gibi gerçek tarayıcı motoru kullanın.

Hata 2: Sticky Session Kullanmamak

Rotating proxy'lerde her istekte IP değişir; bu, _abck'nin imza doğrulamasını bozar. Akamai, token'ın üretildiği IP ile sonraki isteklerin IP'sini karşılaştırır. ProxyHat'ta user-session-XXX flag'i ile sticky session kullanın; 10-30 dakika aynı IP'yi koruyun.

Hata 3: sensor_data'yı Manuel Değiştirmek

Bazı mühendisler, sensor_data payload'unu yakalayıp tekrar oynatmaya çalışır. Bu çalışmaz; çünkü payload içindeki zaman damgaları ve checksum'lar tek kullanımlıktır. bmak motorunun gerçek tarayıcıda çalışmasına izin verin.

Hata 4: Yetersiz Bekleme Süresi

_abck cookie'si, sayfa yüklendikten sonra sensor.js çalıştığında set edilir. Sayfa yüklendikten sonra en az 2-3 saniye bekleyin; aksi halde cookie henüz yerleşmemiş olabilir ve sonraki istekler challenge tetikler.

ProxyHat'a Özel Kurulum ve İç Bağlantılar

ProxyHat, residential, mobile ve datacenter proxy'leri tek panelden sunar. Akamai Bot Manager v2 için residential planı önerilir. Fiylandırma ve plan detayları için ProxyHat fiyatlandırma sayfasını inceleyin.

Web scraping kullanım senaryosu için web scraping use case rehberi, SERP takibi için SERP tracking use case sayfası faydalıdır. Mevcut lokasyonlar ve ASN çeşitliliği için ProxyHat lokasyonları listesine bakın. Teknik API belgeleri için ProxyHat dokümantasyonunu ziyaret edin.

Konkret bir konfigürasyon önerisi: ABD hedefli scraping için user-country-US-session-{id} formatını kullanın; her scraping job'ı için benzersiz session ID atayın ve 500-1000 istek sonunda yeni session açın. Bu, IP tükenmesini ve rate limit tetiklenmesini önler.

Key Takeaways

Önemli Çıkarımlar:

• Akamai Bot Manager v2, üç katmanlı doğrulama kullanır: cookie imzası, sensor_data telemetry ve sunucu tarafı IP skoru. Tek bir katman yeterli değildir.
• _abck cookie'si, sensor_data ile kriptografik olarak bağlıdır; manuel değiştirilemez.
• 2026'da Chrome 131+ için X25519MLKEM768 key share'i ve JA4 TLS parmak izi zorunludur; saf HTTP istemcileri bunları üretemez.
• Veri merkezi ASN'leri başlangıçta bot olarak puanlanır; residential proxy'ler zorunludur.
• Yasal otomasyon için: gerçek tarayıcı motoru + ProxyHat residential proxy + tutarlı timezone/locale + sticky session kullanın.
• Her zaman hedef sitenin robots.txt ve ToS'üne uyun; CFAA ve GDPR kapsamında yetkisiz erişim yasa dışıdır.

SSS

Akamai Bot Manager v2 Derin İnceleme nedir?

Akamai Bot Manager v2, web sitelerini otomatik botlara karşı koruyan kurumsal bir bot tespit sistemidir. Üç katmanlı doğrulama kullanır: _abck imzalı cookie, sensor_data telemetry payload'u ve sunucu tarafı IP itibar skoru. 2026'da TLS JA4 parmak izi ve HTTP/2 SETTINGS çerçevesi de eklenmiştir. Sistem, tek bir tutarsızlıkta tüm oturumu geçersiz kılar.

Akamai Bot Manager v2 proxy kullanıcıları için neden önemli?

Akamai, IP ASN itibarını ağır biçimde ağırlıklandırır. Veri merkezi IP'leri (AWS, Azure) başlangıçta bot olarak puanlanır ve ilk birkaç istekte challenge tetiklenir. Residential proxy'ler, gerçek ISP ASN'lerine ait olduğu için yüksek başlangıç skoru alır. Bu nedenle proxy seçimi, Akamai korumalı sitelerde scraping başarısını doğrudan belirler.

Akamai Bot Manager v2 için hangi proxy türü en iyisi?

Residential proxy'ler en iyi sonucu verir; gerçek ISP ASN'leri yüksek itibar skoru alır ve uzun sticky session süreleri destekler. Mobile proxy'ler de güçlüdür; doğal IP rotasyonu avantajlıdır. Datacenter proxy'ler ise çoğu durumda ilk 50 istekte yakalanır ve yalnızca düşük güvenlikli hedefler için uygundur. ProxyHat residential planı, Akamai korumalı siteler için önerilen seçenektir.

Akamai Bot Manager v2 uygularken blokları nasıl önlersiniz?

Gerçek tarayıcı motoru (Playwright/Puppeteer) kullanın, TLS parmak izi User-Agent ile tutarlı olsun, sticky session ile aynı IP'yi 10-30 dakika koruyun, timezone ve locale'i IP ile eşleştirin ve sensor.js'in gerçek tarayıcıda çalışmasına izin verin. Manuel sensor_data oynatma çalışmaz; her istekte IP değiştirmek _abck imzasını bozar. Hedef sitenin robots.txt ve ToS'üne uyun.