كيفية تجاوز Akamai Bot Manager في 2026

يحمي Akamai Bot Manager عدداً من الأهداف عالية القيمة أكثر من أي نظام آخر مضاد للروبوتات — شركات الطيران، إطلاقات الأحذية الرياضية، حجز التذاكر، كبرى متاجر التجزئة. وهو أيضاً أقدم لاعب في هذا المجال، ما يعني أمرين: أن كشفه هو الأكثر نضجاً، وأن أسلوبه في الحظر هو الأكثر تميزاً. نادراً ما يعرض عليك Akamai اختبار captcha. بل تحصل على 403 صامت على الحافة، أو حلقة إعادة توجيه لا تنتهي، أو — وهي حركته المميزة — صفحة تُحمّل بشكل سليم لكنها تُرجع بيانات مسمومة.

يغطي هذا الدليل ما يفحصه Akamai فعلياً في 2026 ونهجاً عملياً مكوناً من أربع طبقات، بنفس روح دليلنا حول DataDome/PerimeterX ودليل Cloudflare. وينطبق التنبيه نفسه: هذا مخصص لكشط البيانات المتاحة للعموم بمعدلات معقولة، وليس لإساءة الاستخدام.

كيف يقرر Akamai أنك روبوت

يمنح Akamai كل طلب درجة عبر ثلاث طبقات، وتتبع هذه الدرجة جلستك عبر ملف تعريف الارتباط _abck:

1. طبقة الشبكة (قبل أي JavaScript)

• بصمة TLS — شغّل Akamai بصمة TLS منذ زمن أطول من أي طرف آخر. تُعلّم رسالة ClientHello الصادرة عن python-requests أو Go-http عند أول حزمة. راجع شرحنا حول JA3/JA4 لمعرفة كيف يعمل ذلك.
• بصمة HTTP/2 — هذا اختصاص Akamai. تكشف قيم إطار SETTINGS، وزيادات WINDOW_UPDATE، وإطارات الأولوية، وترتيب الترويسات الزائفة (:method :path :authority :scheme مقابل ترتيب Chrome :method :authority :scheme :path) عن عميلك حتى لو كان TLS لديك منتحَلاً. معظم حالات "بصمة JA3 لدي مثالية لكنني ما زلت محظوراً" على مواقع Akamai هي حالات عدم تطابق في بصمة HTTP/2.
• سمعة الـ IP — نوع الـ ASN (مركز بيانات مقابل سكني)، وتاريخ الإساءة المشترك عبر شبكة عملاء Akamai بأكملها.

2. طبقة المستشعر (ملف تعريف الارتباط _abck)

تجمع JavaScript الخاصة بـ Akamai حمولة "sensor_data" مشفّرة كبيرة: مسارات الماوس، توقيت ضغطات المفاتيح، اتجاه الجهاز، تجزئات canvas/WebGL، وآثار الأتمتة. تُرسلها عبر POST إلى النطاق المحمي، ويقوم الرد بترقية (أو تسميم) ملف تعريف الارتباط _abck الخاص بك. يحتوي ملف _abck الصالح على ~0~ في موضع محدد؛ بينما يحتوي الملف المُعلّم على ~-1~. يتغير تنسيق المستشعر كل بضعة أسابيع — ولهذا تموت المستشعرات الملتقطة والمُعاد تشغيلها بسرعة.

3. الطبقة السلوكية

وتيرة الطلبات، وترتيب التصفح (هل وصلت إلى واجهة برمجة المنتج دون أن تُحمّل صفحة المنتج إطلاقاً؟)، وعمر الجلسة. Akamai صبور: فقد يسمح أحياناً بمرور الطلبات القليلة الأولى ثم يحظرك في منتصف الجلسة بمجرد أن تتراكم الدرجة.

الطبقات الأربع لإعداد ناجح

الطبقة 1: عناوين IP سكنية مع جلسات ثابتة

عناوين IP الخاصة بمراكز البيانات ميتة على المواقع المحمية بـ Akamai — فحص الـ ASN وحده يقضي عليها. استخدم بروكسيات سكنية، ولأن ملف تعريف الارتباط _abck مرتبط بجلستك، استخدم جلسات ثابتة: عنوان IP واحد يُحتفظ به طوال عمر هوية واحدة، تدور ملفات تعريف الارتباط وعنوان IP معاً كوحدة واحدة. تُبطل تغييرات الـ IP في منتصف الجلسة ثقة المستشعر التي بنيتها. (الاستراتيجية الكاملة: الجلسات الثابتة مقابل المتناوبة.)

# One sticky identity = one session id, held ~10 min
socks5h://USERNAME:[email protected]:913

الطبقة 2: متصفح حقيقي، أو انتحال كامل

بالنسبة للكشط القائم على HTTP فقط، يجب أن ينتحل عميلك كلاً من TLS وHTTP/2. يفعل curl_cffi كليهما بشكل صحيح:

from curl_cffi import requests

r = requests.get(
    "https://www.target-site.com/api/inventory",
    impersonate="chrome",   # TLS + HTTP/2 fingerprint together
    proxies={"https": "socks5h://USERNAME:[email protected]:913"},
)

استخدام httpx العادي مع تمكين HTTP/2 ليس كافياً — فبصمة h2 الخاصة بـ httpx هي بصمته الخاصة، وليست بصمة Chrome. إذا كنت تحصل على أخطاء 403 مع بصمة TLS نظيفة، فهذا هو السبب دائماً تقريباً. (للخلفية: دليل curl_cffi و tls-client.)

الطبقة 3: اكتسب ملف _abck صالحاً قبل الوصول إلى واجهات برمجة التطبيقات

لأي شيء يتجاوز الصفحات الثابتة، شغّل متصفحاً حقيقياً للمصافحة الأولية للجلسة: حمّل صفحة الهبوط، واترك سكربت المستشعر يعمل، ونفّذ بضعة تفاعلات ذات شكل بشري (تمرير، حركة الماوس)، ثم استخرج ملفات تعريف الارتباط لعميل HTTP الخاص بك — عبر البروكسي ذاته:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME", "password": "PASSWORD",
    })
    page = browser.new_page()
    page.goto("https://www.target-site.com/")
    page.mouse.move(300, 400); page.mouse.wheel(0, 600)
    page.wait_for_timeout(3000)   # sensor POST happens here
    cookies = page.context.cookies()
    abck = next(c["value"] for c in cookies if c["name"] == "_abck")
    # "~0~" in abck -> valid; "~-1~" -> flagged, restart with new identity

الطبقة 4: تصرّف مثل حركة المرور التي تدّعي أنك جزء منها

• اتبع مسار التصفح الحقيقي — صفحة الفئة → صفحة المنتج → واجهة برمجة التطبيقات، ولا تبدأ أبداً بواجهة برمجة التطبيقات أولاً.
• أبقِ معدلات الطلبات لكل هوية بشرية (الشخص لا يفحص 200 وحدة SKU في الدقيقة).
• أحِل الهويات للتقاعد بعد ~50–100 طلب؛ وأعد تدوير عنوان IP إلى المجموعة.
• انتبه إلى الردود المسمومة: أخبث حيل Akamai هي HTTP 200 مع أسعار/مخزون خاطئة بشكل دقيق. تحقّق من القيم المكشوطة مقابل عنصر تحكّم معروف الصحة في كل تشغيلة.

تصحيح الأخطاء: أي طبقة تفشل فيها؟

العَرَض	الطبقة المحتملة	الإصلاح
403 عند أول طلب، دون أي ملفات تعريف ارتباط	بصمة TLS / HTTP/2	انتحال curl_cffi، وليس httpx الخام
الطلبات الأولى سليمة، ثم حظر بعد 5–10	سمعة IP أو وتيرة	جلسات سكنية ثابتة، أبطئ السرعة
يحتوي _abck على ~-1~	المستشعر / آثار الأتمتة	مصافحة بمتصفح حقيقي، مع تفاعل بشري أولاً
200 OK لكن البيانات تبدو خاطئة	رد مسموم	أنت مُعلّم — إعادة تعيين كاملة للهوية
حلقة إعادة توجيه لا تنتهي عند الدخول	حظر على مستوى الحافة لعنوان IP	عنوان IP سكني جديد، تحقّق من أن الـ ASN غير مُعلّم

الخلاصة

• Akamai = بصمة TLS إلى جانب بصمة HTTP/2 على الحافة، وملف تعريف ارتباط مستشعر مشفّر (_abck)، وتسجيل سلوكي صبور.
• عناوين IP الخاصة بمراكز البيانات ميتة؛ والجلسات السكنية الثابتة إلزامية — يجب أن يدور ملف تعريف الارتباط وعنوان IP كهوية واحدة.
• العملاء القائمون على HTTP فقط يحتاجون إلى انتحال كامل (curl_cffi)؛ أما httpx مع h2 فلا يزال يفشل في فحص HTTP/2.
• اكتسب ملف _abck صالحاً بمتصفح حقيقي قبل لمس واجهات برمجة التطبيقات؛ وتحقّق من وجود ~0~.
• احذر من البيانات المسمومة بحالة 200-OK — تحقّق منها مقابل عنصر تحكّم في كل تشغيلة.