أطلقت Cloudflare بالأمس نظاماً لاكتشاف البوتات على مستوى الجلسة
في 13 يوليو 2026، أطلقت Cloudflare محرك Precursor، وهو محرك مستمر لاكتشاف سلوك البوتات يراقب الجلسة بأكملها، وليس فقط لحظة وصول الزائر. يعمل اختبار Turnstile الحالي لديهم حوالي 3 مليارات مرة يومياً عند تسجيل الدخول، والاشتراك، وإتمام الدفع. يوسع Precursor هذا النطاق من الرؤية من جانب العميل ليشمل كل صفحة بين تلك الخطوات.
طريقة العرض مهمة هنا. طرح Turnstile سؤالاً واحداً في لحظة واحدة: هل هذا الزائر بشري؟ أما Precursor فيطرح السؤال نفسه باستمرار، عبر كل حركة ماوس، وضغطة مفتاح، والتمرير، وتغيير التركيز، ويغذي الإجابة في تقييم تشغيل للبوت (bot score) يرافق الجلسة.
هذا تغيير أكبر مما يبدو عليه في البيان الصحفي.
الجلسة هي البصمة الجديدة
لسنوات، اعتمد اكتشاف البوتات على دفعات قصيرة: فحص واحد عند المدخل، ثم ملف cookie يضمن الزائر لفترة من الوقت. وحتى عمليات فحص الترويسات (headers) وفحوصات مستوى الشبكة الأحدث كانت أحداثاً تجري لكل طلب (per-request). إذا اجتزت الاختبار الأول، فأنت في أمان غالباً حتى الاختبار التالي.
يكسر الاكتشاف السلوكي على مستوى الجلسة هذا النمط. وفقاً لمنشور إطلاق Cloudflare: يمكن للبوتات تنفيذ JavaScript، واستخدام بيئات متصفح كاملة، وإكمال التحديات الفردية دون إثارة الشبهات. لكن ما يظل من الصعب تكراره هو السلوك البشري المتسق بمرور الوقت.
يستشهدون بفيزياء الإدخال البشري كعائق تصطدم به الأتمتة. حركة ماوس الإنسان تكون على شكل قوس، محدودة بحركة المعصم ودوران الساعد. وهناك تأخير قابل للقياس بين رؤية خانة الاختيار والنقر عليها (العبء المعرفي). وحتى اليد الثابتة تتذبذب بتردد ارتعاش فسيولوجي. في المقابل، تُنتج البوتات خطوطاً مستقيمة ومنحنيات Bezier نظيفة رياضياً، وتنقر بدقة لا يصل إليها أي إنسان.
أي إشارة من هذه الإشارات يصعب تمييزها بمفردها. لكن عند جمعها عبر جلسة مدتها خمس دقائق، يصبح التباين واضحاً جداً.
لماذا لم يعد التحديث مفيداً
كان النمط القديم تحت نظام الاكتشاف لكل طلب بسيطاً: إذا ارتفع تقييم الجلسة، قم بتحديث الصفحة، وتدوير الهوية، والبدء من جديد. يغلق Precursor هذا الباب.
توضح Cloudflare ذلك صراحة: "يُعد تحديد نطاق الجلسة أمراً مهماً لأنه يعني أن البوت لا يمكنه إعادة تعيين بصمته السلوكية عن طريق تحديث الصفحة أو البدء من جديد بتحدٍّ جديد." الجلسات المشبوهة تجمع السياق، وتقييم البوت يتبع الزائر.
لكن هذا التغيير يضرب فئة متوسطة محددة من أدوات الكشط (scrapers) بقوة أكبر. كان نموذج المتصفح غير المرئي (headless) بالكامل مع التدوير لكل طلب يخسر بالفعل أمام عمليات الفحص القياسية، ولا جديد في ذلك. أما المشغلون الذين يدركون طبيعة الجلسات تماماً، ويديرون هوية متصفح واحدة طوال مدة زيارة مستخدم حقيقي، فهم في وضع جيد إلى حد كبير. يعاقب Precursor ما يقع بينهما: الفرق التي تشغل Puppeteer أو Playwright بإعدادات افتراضية معقولة، وتتعامل مع كل رابط URL كعملية مستقلة، وتقوم بالتحديث بين عمليات الزحف لتبدو نظيفة.
هذا النمط من الكشط رخيص لأنه سريع الاستهلاك والتخلص. وPrecursor يجعل ما يُستهلك مكلفاً.
ماذا يعني هذا بالنسبة لأدوات الكشط المعتمدة على الوكلاء (Agentic Scrapers)
هناك فئة ثانية صُمم Precursor بوضوح لرصدها: أدوات الكشط المعتمدة على الوكلاء الذكيين (agentic AI). تشير Cloudflare إلى ذلك بوضوح في العنوان الفرعي: اكتشاف السلوك القائم على الوكلاء عبر إشارات متواصلة من جانب العميل.
وكلاء التصفح الذاتيون (النوع المدفوع بنماذج LLM والذي يخطط للمهمة وينفذها خطوة بخطوة) يميلون إلى التحرك في فترات قصيرة وحاسمة. انتقال، استخراج، انتقال، استخراج. يبدو كل إجراء بمفرده وكأنه شيء قد يفعله زائر حقيقي. لكن لا يوجد وقت مكوث، ولا نمط تمرير للقراءة، ولا تصحيحات طفيفة، ولا تجاوز للهدف بالماوس. وعلى مدار الجلسة، تصبح هذه الغيابات واضحة ومكشوفة تماما مثل اهتزازات الماوس المزيفة.
لذلك، إذا كنت تبني وكيلا يجمع البيانات أثناء تفكيره، فإن ضريبة المحاكاة الفعلية أصبحت واقعا. تذكر مدونة Cloudflare أن Precursor "يرفع تكلفة تشغيل الأتمتة عبر إلزامها بمحاكاة جلسة كاملة. بناء ذلك أصعب بكثير، وصيانته أعلى تكلفة، وتشغيله على نطاق واسع أقل موثوقية بكثير."
هذا هو الهدف الكامل من التصميم. ليس جعل الأتمتة مستحيلة، بل جعلها غير مجدية اقتصاديا.
ماذا يعني هذا لفرق البيانات
تتغير ثلاثة أمور أساسية، ولا شيء منها منخفض التكلفة.
أولا، تحل ميزانيات الجلسات محل ميزانيات request. إذا كنت تخطط للسعة الاستيعابية لهدف محمي بواسطة Cloudflare، توقف عن التفكير بعدد requests في الثانية وابدأ بالتفكير بالجلسات في الساعة: كم عدد رحلات المستخدم المستقلة التي تبدو متواصلة والتي يمكنك الحفاظ عليها، وما هي مدة كل منها؟ الفترات القصيرة والمتقطعة هي البصمة الدقيقة التي تم ضبط Precursor لاكتشافها. إن إعادة التفكير في حسابات proxy التي كتبنا عنها في مايو تنطبق هنا أيضا. حجم المجمع ليس هو الحد الأقصى، بل واقعية الجلسة هي المعيار.
ثانيا، تميل معادلة البناء مقابل الشراء (build vs buy) بشكل أكبر نحو الشراء. صيانة أداة كشط ضد نظام دفاع يعمل على مستوى كل request تتطلب تكاملا لمرة واحدة وتحديثات دورية طفيفة. أما صيانتها ضد نظام دفاع يعمل على نطاق الجلسة فتعني بحثا وتطويرا سلوكيا مستمرا: نماذج ضبط وتيرة الحركة، ومسارات المؤشر، وتوزيعات أوقات المكوث، وطريقة للحفاظ على تغطية الاختبار لكل ذلك. إذا كنت مترددا بشأن الاستعانة بمصادر خارجية لجمع بيانات الويب، فإن هذا يزيد من سوء الجدوى الاقتصادية للبناء الداخلي.
ثالثا، من يطلق Precursor على نطاق واسع أولا سيحدد المعيار الأساسي الجديد للاكتشاف في هذا المجال. تحمي Cloudflare ما يقرب من 20% من الويب. وإذا قام عملاء التجارة الإلكترونية والخدمات المالية بتفعيل Precursor بشكل مكثف خلال الربع القادم، فستتأثر بنية الكشط لدى الجميع، بما في ذلك المواقع التي لا تعتمد Precursor مطلقا، لأن منظومة الحماية تراقب ما ينجح وتنسخه بسرعة.
التحول في النطاق الزمني الذي لا يذكره أحد
كتبنا عن الاتجاه نحو الاكتشاف السلوكي منذ ثلاثة أشهر. يعد Precursor التجسيد التجاري الفعلي لهذا الاتجاه، وهو يعيد ضبط نافذة القياس من جديد.
كان اكتشاف الـ bot يتم سابقًا في نطاق request واحد. أما الآن فهو يحدث عبر جلسة تمتد لدقائق، وأحيانًا أطول من ذلك. هذا التغيير الفردي يُلقي بظلاله على كل أسلوب scraping كُتب عندما كانت وحدة الاكتشاف عبارة عن استدعاء واحد فقط. تدوير الـ proxy، وتغيير الـ header عشوائيًا، وضبط وتيرة الـ request على مقياس الثواني، تفقد جميعها أهميتها إذا كانت دالة الخسارة (loss function) تعتمد على التناسق السلوكي عبر 5 دقائق من التفاعل.
السؤال ليس ما إذا كان اكتشاف الـ bot يستمر في التطور، فهذا أمر مفروغ منه. السؤال هو ما إذا كانت بنية جمع البيانات لديك لا تزال تفكر بمنطق الـ requests، بينما يفكر المدافع بمنطق الجلسات.