داخلية Cloudflare Turnstile: كيف يكشف البوت ويمنح الثقة في 2026

إذا كنت مهندس كشط بيانات أو باحث أمن ويب، فلا بد أنك اصطدمت بصفحة Cloudflare Turnstile التي تعرض تحديًا غير مرئي قبل أن تسمح لك بالوصول إلى المحتوى. فهم داخلية Cloudflare Turnstile لم يعد ترفًا — بل هو الفرق بين جلسة تستمر ساعات وجلسة تُحظر خلال 200 مللي ثانية من أول طلب.

تنويه قانوني: هذه المقالة مخصّصة للأتمتة المصرّح بها، والوصول إلى البيانات العامة، وأبحاث الأمان الشرعية. استخدام هذه التقنيات لانتحال الهوية، أو تجاوز مصادقة المستخدم، أو انتهاك شروط الخدمة قد يعرّضك لمسؤولية بموجب قانون الاحتيال وإساءة استخدام الكمبيوتر (CFAA) في الولايات المتحدة واللائحة العامة لحماية البيانات (GDPR) في الاتحاد الأوروبي. راجع قانون CFAA والمادة 5 من GDPR قبل أي تنفيذ.

ما هي داخلية Cloudflare Turnstile وكيف تعمل في 2026؟

Turnstile هو نظام تحدٍّ مُدار يعمل ضمن منصة Cloudflare Bot Management. بدلًا من عرض اختبار CAPTCHA تقليدي يطالب المستخدم بحل أحجية، يقوم Turnstile بتشغيل كود JavaScript غير مرئي يجمع إشارات من المتصفح ويبني درجة ثقة (Trust Score) في الخلفية. إذا كانت الدرجة مرتفعة، يُمنح الزائر ملف تعريف ارتباط يُسمى cf_clearance يُتيح له تجاوز التحديات اللاحقة لمدة محددة.

التحدي المُدار يُنفّذ سلسلة من الفحوصات المتزامنة:

• إثبات العمل (Proof-of-Work): كود JavaScript يحلّ مهمة حسابية (عادةً تعديل تجزئة SHA بسيط) لإثبات أن الطرف يملك معالجًا حقيقيًا يستغرق وقتًا فعليًا. زمن الحل يُقاس بالميلي ثانية ويُقارن بحدود متوقعة لمتصفح حقيقي.
• فحوصات واجهات برمجة المتصفح (Browser API Probes): فحص وجود خصائص مثل navigator.webdriver، وwindow.chrome، وnavigator.permissions، وقياس سلوك WebGLRenderingContext وAudioContext للكشف عن الأتمتة.
• تحليل السلوك (Behavioral Telemetry): حركة المؤشر، توقيتات الضغط على المفاتيح، أحداث التمرير، وتسارع الأجهزة (DeviceMotion) تُجمع وتُحلّل لاكتشاف النمط الآلي.

عند نجاح التحدي، يُصدر خادم Cloudflare ملف cf_clearance مرتبطًا صارمًا بـ User-Agent + عنوان IP. أي تغيير في أحدهما يُبطل الملف فورًا.

السياق التقني: لماذا توجد هذه المشكلة

تطوّرت أنظمة مكافحة البوت من قوائم IP بسيطة إلى أنظمة ثقة متعددة الإشارات. وفقًا لـ وثائق Cloudflare Bot Management، تستخدم المنصة أكثر من 30 إشارة لتقييم كل طلب. السبب الجذري للصراع هو أن أدوات الأتمتة الحديثة (Playwright، Puppeteer، Selenium) تُنتج بصمات متصفح قريبة من المتصفح الحقيقي لكنها تترك آثارًا دقيقة: ترتيب امتدادات TLS، رؤوس HTTP/2، واختلافات في واجهات JavaScript.

المشكلة التي يواجهها مهندسو الكشط هي أن أي عدم تطابق بين ما يدّعيه الاتصال (User-Agent يقول Chrome) وبين ما يُقدّمه فعليًا (بصمة JA4 تقول Python) يُؤدي إلى تحدٍّ فوري. هذا التطابق بين الطبقات هو جوهر cloudflare bot management ja4.

بصمة JA4: كيف تُرتّب امتدادات TLS قبل التجزئة

JA4 هو معيار بصمة TLS طورته FoxIO، ويُماثل بصمة JA3 القديمة لكنه أبسط وأكثر قابلية للقراءة. الفكرة الأساسية: بدلًا من تجزئة قائمة امتدادات TLS كما وردت، يُعيد JA4 ترتيبها أبجديًا قبل التجزئة. هذا يجعل البصمة مستقرة بغض النظر عن ترتيب إرسال الخادم أو العميل للامتدادات.

صيغة JA4:

ja4 = t + version + alpn + extensions_sorted_hash + signature_algorithms_hash

مثال بصمة Chrome 120 الحقيقية:

ja4 = t13d1516h2_8daaf6152771_b186095e2266

بينما بصمة مكتبة requests في Python (التي تستخدم OpenSSL) تختلف تمامًا:

ja4 = t13d1516h2_000000000000_e3b0c44298fc

الاختلاف في تجزئة الامتدادات (الجزء الأوسط) يكشف فورًا أن الاتصال ليس متصفحًا حقيقيًا حتى لو كان User-Agent يقول Chrome/120. وفقًا مستودع FoxIO لمعيار JA4، الترتيب الأبجدي يضمن أن البصمة تعكس مجموعة الامتدادات لا ترتيبها العشوائي.

إشارات درجة الثقة الأربع في Cloudflare Bot Management

يدمج Cloudflare أربع إشارات رئيسية في درجة ثقة واحدة:

إذا تطابقت الإشارات الأربع، يُمنح الطلب درجة ثقة عالية. إذا تعارضت إشارة واحدة فقط — مثل User-Agent يقول Chrome لكن JA4 يقول Python — يُخفض التصنيف فورًا ويُعرض التحدي.

لماذا يُكتشف اتصال يدّعي Chrome لكنه يُقدّم بصمة JA4 لـ Python فورًا

هذا السيناريو هو أكثر أسباب الحظر شيوعًا. يحدث عندما يستخدم مطور requests أو httpx أو aiohttp رأس User-Agent لمتصفح Chrome لكنه يبني الاتصال عبر مكتبة TLS مختلفة (OpenSSL بدلًا من BoringSSL الذي يستخدمه Chrome). النتيجة:

• رأس HTTP يقول: User-Agent: Mozilla/5.0 ... Chrome/120
• بصمة JA4 تقول: t13d1516h2_000000000000_... (Python OpenSSL)

Cloudflare يرى التناقض ويُصنّف الطلب على أنه بوت. لا يهم كم تُقنّع رؤوس HTTP — البصمة على طبقة TLS تكشف الحقيقة. هذا هو السبب الذي يجعل استخدام متصفح حقيقي (مثل Playwright مع Chromium حقيقي) أكثر فعالية من محاكاة المتصفح عبر مكتبات HTTP.

لماذا تُهم البروكسيات السكنية: cf_clearance مرتبط بـ IP

ملف cf_clearance ليس مجرد رمز عشوائي — إنه رمز موقّع مرتبط بـ:

1. User-Agent (سلسلة كاملة)
2. عنوان IP الذي حصل على التحدي
3. الموقع الجغرافي (منطقة Cloudflare)

إذا حصلت على cf_clearance عبر IP سكني ثم غيّرت بروكسياتك إلى IP آخر (حتى لو كان سكنيًا آخر)، يرفض Cloudflare الملف ويطلب تحديًا جديدًا. هذا يعني أن عنوان IP المستقر يجب أن يحمل الجلسة بأكملها.

هنا تكمن قيمة البروكسيات السكنية الثابتة (Sticky Residential): عنوان IP واحد يبقى ثابتًا طوال الجلسة، مما يسمح بإعادة استخدام cf_clearance عبر طلبات متعددة دون إعادة التحدي.

نهج عملي: استخدام جلسات ProxyHat السكنية الثابتة مع متصفح حقيقي

إليك نهجًا مشروعًا للحفاظ على جلسة نظيفة عبر Cloudflare Turnstile:

الخطوة 1: إنشاء جلسة سكنية ثابتة

استخدم ProxyHat مع معرّف جلسة ثابت في اسم المستخدم للحفاظ على نفس عنوان IP طوال الجلسة:

# ProxyHat HTTP proxy with sticky session
http://user-session-abc123:pass@gate.proxyhat.com:8080

# ProxyHat SOCKS5 (if you need SOCKS5)
socks5://user-session-abc123:pass@gate.proxyhat.com:1080

يمكنك أيضًا تحديد الدولة:

http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

الخطوة 2: تشغيل متصفح حقيقي عبر البروكسيات

مثال باستخدام Playwright مع Chromium حقيقي في Python:

from playwright.sync_api import sync_playwright

proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-session-abc123",
    "password": "pass"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,
        proxy=proxy_config,
        args=["--disable-blink-features=AutomationControlled"]
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/120.0.0.0 Safari/537.36"
    )
    page = context.new_page()
    page.goto("https://example-protected.com")
    # انتظر حتى يكتمل تحدي Turnstile
    page.wait_for_timeout(5000)
    # استخراج cf_clearance
    cookies = context.cookies()
    cf_clearance = next(
        (c for c in cookies if c["name"] == "cf_clearance"), None
    )
    if cf_clearance:
        print(f"cf_clearance: {cf_clearance['value']}")
    browser.close()

الخطوة 3: إعادة استخدام cf_clearance عبر طلبات لاحقة

بعد الحصول على cf_clearance، يمكنك إعادة استخدامه عبر طلبات HTTP اللاحقة طالما بقيت على نفس IP ونفس User-Agent:

import requests

proxies = {
    "http": "http://user-session-abc123:pass@gate.proxyhat.com:8080",
    "https": "http://user-session-abc123:pass@gate.proxyhat.com:8080"
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                 "AppleWebKit/537.36 (KHTML, like Gecko) "
                 "Chrome/120.0.0.0 Safari/537.36",
    "Cookie": "cf_clearance=YOUR_TOKEN_HERE"
}

response = requests.get(
    "https://example-protected.com/api/data",
    headers=headers,
    proxies=proxies
)
print(response.status_code)

ملاحظة مهمة: يجب أن يبقى عنوان IP ثابتًا. إذا انتهت الجلسة الثابتة (حسب إعدادات ProxyHat)، ستحتاج إلى إعادة الحصول على cf_clearance عبر المتصفح مرة أخرى.

الخطوة 4: إدارة دورة حياة الجلسة

للحفاظ على الجلسة لفترات طويلة، استخدم نفس معرّف الجلسة (session-abc123) طوال الوقت. إذا كنت تدير 100 جلسة متزامنة، استخدم معرّفات جلسات فريدة لكل واحدة:

# Session 1
http://user-session-sess001:pass@gate.proxyhat.com:8080
# Session 2
http://user-session-sess002:pass@gate.proxyhat.com:8080
# Session 100
http://user-session-sess100:pass@gate.proxyhat.com:8080

راجع صفحة أسعار ProxyHat لاختيار الخطة المناسبة لعدد الجلسات المتزامنة التي تحتاجها.

متى يكون هذا النهج مناسبًا — ومتى لا يكون

مناسب لـ:

• أتمتة مصرّح بها عبر API رسمية أو شروط خدمة تسمح بالوصول الآلي.
• كشط بيانات عامة لا تتطلب تسجيل دخول (أسعار المنتجات، نتائج SERP).
• أبحاث الأمان الشرعية على أصول تملكها أو لديك إذن اختبارها.
• مراقبة توفر الخدمة لموقعك الخاص.

غير مناسب لـ:

• انتحال هوية مستخدمين مسجّلين أو سرقة بيانات اعتماد.
• تجاوز مصادقة ثنائية العامل.
• كشط بيانات شخصية محمية بـ GDPR دون أساس قانوني.
• الهجمات الموزعة (DDoS) أو إغراق الخدمات.

للمزيد عن حالات الاستخدام الشرعية، راجع صفحة كشط الويب وتتبّع نتائج SERP.

أخطاء شائعة وحالات حدية

1. تغيير User-Agent بعد الحصول على cf_clearance

إذا حصلت على cf_clearance عبر Chrome 120 ثم استخدمت نفس الملف مع User-Agent يقول Firefox، يُرفض الملف فورًا. احفظ User-Agent المستخدم في المتغيرات وأعد استخدامه حرفيًا.

2. استخدام بروكسيات دوّارة لكل طلب

البروكسيات الدوّارة لكل طلب (per-request rotation) ممتازة لكشط المواقع التي لا تستخدم Turnstile، لكنها كارثة مع Turnstile لأن cf_clearance مرتبط بـ IP. استخدم الجلسات الثابتة مع Turnstile.

3. تجاهل بصمة HTTP/2 SETTINGS

حتى لو استخدمت متصفحًا حقيقيًا، فإن تمرير الطلبات عبر مكتبة HTTP مختلفة (مثل requests التي تستخدم HTTP/1.1) قد يكشف الاتصال. استخدم httpx مع HTTP/2 أو الأفضل، استخدم المتصفح نفسه لجميع الطلبات.

4. نسيان أن cf_clearance ينتهي

مدة صلاحية cf_clearance تختلف حسب إعدادات الموقع — قد تكون من 30 دقيقة إلى 24 ساعة. ابنِ منطقًا يكتشف انتهاء الصلاحية (عادةً عبر HTTP 403 أو إعادة توجيه إلى صفحة تحدٍّ) ويُجدّد الملف تلقائيًا.

مقارنة أنواع البروكسيات لسيناريوهات Turnstile

راجع صفحة مواقع ProxyHat لاختيار المواقع الجغرافية المناسبة لجمهورك المستهدف.

النقاط الرئيسية

الخلاصة: تجاوز Cloudflare Turnstile ليس عن كسر التشفير — بل عن تقديم بصمة متّسقة عبر كل الطبقات: TLS (JA4)، HTTP/2، المتصفح (Canvas/WebGL)، وIP (سكني ثابت). أي تعارض بين طبقة واحدة وأخرى يُسفِر عن تحدٍّ.

• cf_clearance مرتبط بـ User-Agent + IP — لا تغيّرهما بعد الحصول على الملف.
• بصمة JA4 تكشف مكتبة TLS المستخدمة بغض النظر عن رأس User-Agent.
• استخدم متصفحًا حقيقيًا (Playwright + Chromium) للحصول على cf_clearance، ثم أعد استخدامه عبر طلبات HTTP.
• استخدم جلسات ProxyHat السكنية الثابتة (session-abc123) للحفاظ على نفس IP طوال الجلسة.
• هذا النهج للأتمتة الشرعية فقط — احترم CFAA وGDPR وشروط الخدمة.

للمزيد من التفاصيل التقنية حول إعداد البروكسيات، راجع وثائق ProxyHat.