نظام مكافحة البوتات هو برنامج يوضع أمام موقع ويب لتقدير، لكل طلب، مدى احتمالية أن يكون آليًا وليس بشريًا، ويتصرف بناءً على هذا التقدير — إما بالسماح به، أو إبطائه، أو تحديه، أو حظره. لا يُبنى التقدير على أي حقيقة واحدة. إنه نتيجة تُجمَّع من أربع طبقات: من أين يأتي الطلب (IP)، وكيف تم إنشاء الاتصال (بصمات TLS وHTTP)، وما يكشفه المتصفح عن نفسه (بصمة JavaScript)، وما يفعله الزائر بمرور الوقت (السلوك). فهم الطبقات يفسر الأمرين الأكثر إرباكًا لمستخدمي البروكسي: لماذا لا يزال عنوان IP سكني "مثالي" يتعرض للتحدي، ولماذا يعمل نفس الإعداد على موقع ويفشل على آخر.
البائعون والمنتجات
تستخدم معظم المواقع المحمية واحدًا من عدد قليل من المنتجات: Cloudflare Bot Management (وتحدي Turnstile الخاص به)، DataDome، Akamai Bot Manager، HUMAN (المعروف سابقًا باسم PerimeterX)، Imperva (Incapsula)، Kasada، وAWS WAF Bot Control. تختلف هذه المنتجات في التركيز وفي مدى عدوانية إعداداتها الافتراضية، لكنها مبنية على نفس الطبقات الأربع، والطبقات هي موضوع هذا المقال. كل ما يلي ينطبق على جميعها بنسب متفاوتة.
الطبقة 1: سمعة IP
الفحص الأول والأرخص. قبل حتى تحليل الطلب، يتم البحث عن الـ IP:
- ASN والنوع — هل هذا من شركة استضافة (مركز بيانات)، أو مزود خدمة إنترنت استهلاكي (سكني)، أو مشغل شبكة جوال؟ تبدأ ASNs الاستضافة بغرامة على معظم المواقع؛ السبب مغطى في سكني مقابل مركز بيانات مقابل جوال.
- استخبارات التهديدات — هل الـ IP مدرج في قوائم إساءة الاستخدام، أو معروف كمخرج VPN/بروكسي، أو شوهد وهو يهاجم عملاء آخرين لنفس البائع؟ يجمع البائعون الإشارات عبر قاعدة عملائهم بأكملها، لذا فإن الـ IP المحروق على موقع محمي بواسطة DataDome يصبح مشبوهًا على جميع المواقع الأخرى.
- السرعة — كم عدد الطلبات التي أرسلها هذا الـ IP إلى هذا الموقع مؤخرًا، وإلى عدد المسارات المختلفة؟ عداد لكل IP هو أقدم إشارة بوت ولا يزال واحدًا من أكثرها فعالية.
- الجغرافيا — هل تتطابق الدولة مع جمهور الموقع؟ هل تتطابق مع اللغة والمنطقة الزمنية التي سيبلغ عنها المتصفح لاحقًا؟
هذه هي الطبقة الوحيدة التي يتحكم فيها البروكسي مباشرة. الـ IP السكني أو الجوال الذي ليس له تاريخ على الهدف يجتازها. لكن اجتياز الطبقة 1 يعني فقط أن الطلب ينتقل إلى الطبقات 2–4 بنتيجة محايدة، وليست جيدة.
الطبقة 2: بصمات الشبكة (TLS، HTTP/2، TCP)
قبل تقديم أي محتوى صفحة، يكون الخادم قد رأى بالفعل كيف تم فتح الاتصال، والطريقة التي تم بها فتحه تحدد برنامج العميل:
- بصمة TLS (JA3/JA4) — يكشف ClientHello عن مكتبة TLS: Chrome، Firefox، OpenSSL-in-Python، Go. مشروح في بصمة TLS.
- بصمة HTTP/2 — قيم إطار SETTINGS، وحجم النافذة الأولي، وإطارات الأولوية، وترتيب الرؤوس والرؤوس الزائفة. للمتصفحات أنماط مميزة ومستقرة؛ لدى مكتبات HTTP أنماط مختلفة. جعل بحث Akamai هذه التقنية مشهورة.
- بصمة TCP/IP — حجم النافذة، TTL، الخيارات؛ يميز أنظمة التشغيل، وعدم تطابق "Windows" User-Agent مع حزمة TCP لنظام Linux هو تناقض.
منطق التسجيل هنا هو الاتساق: هل تتطابق الهوية على مستوى الشبكة مع ما تدعيه رؤوس HTTP؟ لا يلمس البروكسي هذه البصمات — فهو يمررها — لذا فإن السكربت خلف IP سكني يتم التعرف عليه كسكربت في هذه الطبقة بغض النظر عن جودة الـ IP. هذا هو المكان الذي تُجاب فيه معظم أسئلة "لماذا يتم حظر البروكسي النظيف الخاص بي؟".
الطبقة 3: بصمة المتصفح وتحديات JavaScript
إذا وصل الطلب إلى نقطة تقديم HTML، فإن JavaScript الخاص بالبائع يعمل في متصفح الزائر ويبلغ بالنتائج. يحدث نوعان من الأشياء.
البصمة
يجمع السكربت نفس الخصائص التي تم بناء المتصفح المضاد للاكتشاف للتحكم فيها: تجزئات canvas وWebGL، والخطوط، وأبعاد الشاشة والنافذة، وتزامن الأجهزة، والمنطقة الزمنية، واللغات، وسياق الصوت، وIPs المرئية عبر WebRTC، وقوائم الإضافات، وعشرات الإشارات الأصغر. كما يتحقق من آثار الأتمتة: navigator.webdriver مضبوط على true، أو كائنات خاصة بـ Chrome مفقودة أو غير متناسقة، أو أخطاء في وضع headless في العرض، أو عدد غير عادي من بعض واجهات برمجة التطبيقات التي تم تجاوزها (علامة على إضافات التخفي التي ترقع المتصفح). ويتحقق من الاتساق: هل تتطابق المنصة المبلغ عنها عبر JavaScript مع OS بصمة TCP؟ هل تتطابق المنطقة الزمنية مع بلد الـ IP؟ انظر ما الذي يتحكم فيه المتصفح المضاد للاكتشاف.
التحديات
يصدر البائعون أيضًا مهام إثبات العمل أو إثبات البشرية. يعمل Turnstile من Cloudflare والصفحة الوسيطة "جارٍ التحقق من متصفحك" على حمل عمل JavaScript يجب إرسال نتيجته مرة أخرى؛ العميل الذي لا يمكنه تنفيذ JavaScript على الإطلاق — كل مكتبة HTTP عادية — يفشل ببساطة ولا يرى الصفحة أبدًا. تُعد CAPTCHAs المرئية الملاذ الأخير، وتظهر عندما تكون النتيجة سيئة ولكنها ليست سيئة بما يكفي للحظر outright. عادةً ما يؤدي اجتياز التحدي إلى ملف تعريف ارتباط أو رمز مميز صالح لفترة؛ الأتمتة التي تمسح ملفات تعريف الارتباط في كل طلب تواجه التحدي في كل مرة، وهو في حد ذاته إشارة.
الطبقة 4: السلوك
عبر جلسة — وعبر جلسات يمكن للبائع ربطها بالبصمة أو الـ IP — يراقب النظام ما يفعله الزائر:
- أنماط الطلبات: الصفحات في الدقيقة، وما إذا كانت الصور والسكربتات المشار إليها في الصفحة يتم جلبها (متصفحات البشر تجلبها؛ أدوات الكشط الساذجة لا تفعل)، وما إذا كان التنقل يتبع الروابط أو يقفز مباشرة إلى عناوين URL عميقة، وما إذا كانت نفس المسارات تُضرب بنفس الترتيب في كل جلسة.
- التوقيت: الفواصل الزمنية المنتظمة بين الطلبات تشبه الآلة؛ البشر متقطعون وغير منتظمين.
- التفاعل: حركة الماوس، والتمرير، وأحداث المفاتيح — وجودها، وشكلها (مسارات الماوس الحقيقية تنحني وتتجاوز؛ المسارات المكتوبة خطوط مستقيمة أو أقواس مثالية).
- شكل الجلسة: تسجيل دخول يتبعه فورًا إجراء جماعي؛ عملية دفع بدون تصفح؛ إنشاء حساب من بصمة أنشأت خمسة حسابات بالأمس.
السلوك هو السبب في أن الإعداد المثالي تقنيًا — متصفح حقيقي، بروكسي متطابق، بصمة نظيفة — يمكن أن يُكتشف إذا تصرف مثل الآلة. وهو أيضًا الطبقة التي تعيش فيها السمعة المتراكمة: الهوية التي تصرفت بشكل طبيعي لأسابيع تكسب تسامحًا لا تحصل عليه الهوية الجديدة. هذا هو معنى "الإحماء" عمليًا.
كيف تتحد الطبقات: النتيجة
تساهم كل طبقة بالأدلة؛ يجمع المنتج بينها في نتيجة بوت (يكشف Cloudflare عن نتيجته من 1 إلى 99؛ والبعض الآخر يبقيها داخلية) ويقوم مالك الموقع بتكوين عتبات: فوق X، اسمح؛ بين X وY، تحدَّ؛ تحت Y، احظر أو قدم طُعمًا. خاصيتان لهذا التصميم مهمتان لأي شخص يستخدم البروكسيات:
- يجب أن تتفق الطبقات. النتيجة ليست مجموع علامات جيدة مستقلة؛ التناقضات تُوزن بشكل كبير. الـ IP السكني (جيد) بالإضافة إلى بصمة TLS الخاصة بـ Python (سيئة) بالإضافة إلى User-Agent الخاص بـ Chrome (تناقض) يسجل أسوأ من IP مركز بيانات مع UA صادق
python-requests، لأن الثاني متماسك على الأقل. - لا يتم فحص أي شيء بمعزل عن الآخر. اجتياز سمعة IP يشتري لك الدخول إلى الفحص التالي، وليس نجاحًا. كل ادعاء تقدمه — عبر IP، أو مصافحة، أو رأس، أو JavaScript، أو سلوك — يتم استجوابه مقابل كل ادعاء آخر.
ماذا يعني هذا لاختيار البروكسي
| الطبقة | ما الذي يحددها | هل يمكن للبروكسي إصلاحها؟ |
|---|---|---|
| 1. سمعة IP | نوع IP، التاريخ، السرعة، الجغرافيا | نعم — هذه هي وظيفة البروكسي الأساسية |
| 2. بصمات الشبكة | عميل HTTP / المتصفح الخاص بك | لا — يتم تمريرها دون تغيير |
| 3. بصمة المتصفح / تحدي JavaScript | متصفحك وإعداداته | لا — لكن الجغرافيا والمنطقة الزمنية يجب أن تتطابق مع البروكسي |
| 4. السلوك | منطق الأتمتة والإيقاع الخاص بك | لا — على الرغم من أن التناوب يؤثر على سرعة كل IP |
لذا: اختر نوع البروكسي الذي تتطلبه سياسة الطبقة 1 للهدف (مركز بيانات حيث يُسمح به، سكني أو جوال حيث لا يُسمح)، ثم أنفق جهدك على الطبقات 2–4، التي لا يلمسها أي بروكسي. عمليًا، هذا يعني متصفحًا حقيقيًا أو منتحلًا للهوية للأهداف المحمية، واتساق بصمة لكل هوية، وجغرافيا ومنطقة زمنية متطابقة مع الـ IP، وإيقاعًا بشريًا. تتفاعل استراتيجية التناوب مع سرعة الطبقة 1 وشكل جلسة الطبقة 4 في نفس الوقت — انظر اختيار فترة التناوب.
كيف تعرف أي طبقة توقفك
- حظر فوري، بدون HTML، حتى من متصفح حقيقي على نفس الـ IP ← الطبقة 1: الـ IP أو ASN هو المشكلة. غيّر نوع البروكسي أو المزود.
- المتصفح ينجح، السكربت على نفس الـ IP لا ينجح ← الطبقة 2: بصمة TLS/HTTP. انتقل إلى متصفح حقيقي أو عميل منتحل.
- صفحة وسيطة لا تُحل أبدًا، أو CAPTCHA في كل زيارة ← الطبقة 3: فشل تحدي JavaScript أو بصمة غير متناسقة. تحقق من علامات الأتمتة، وWebRTC، والمنطقة الزمنية مقابل الـ IP.
- يعمل لفترة ثم يتدهور؛ أو تموت الحسابات بعد إجراءات ← الطبقة 4: السلوك أو السرعة. أبطئ، ونوّع الأنماط، وقم بإحماء الهويات.
يعيد البائعون استجابات مميزة (صفحة 403 من Cloudflare، ورؤوس x-datadome ونقطة نهاية CAPTCHA من DataDome، وملف تعريف الارتباط _abck من Akamai)، لذا فإن تحديد أي منتج يستخدمه الموقع عادةً ما يكون مسألة النظر إلى الرؤوس وملفات تعريف الارتباط — ومعرفة المنتج يخبرك بالطبقات التي يركز عليها.
الأسئلة الشائعة
ما هي نتيجة البوت؟
تقدير لكل طلب، يتم إنتاجه من خلال الجمع بين سمعة IP وبصمات الشبكة والمتصفح والإشارات السلوكية، لمدى احتمالية أن يكون الطلب آليًا. يحدد مالكو المواقع عتبات عليه للسماح أو التحدي أو الحظر.
لماذا لا يزال البروكسي السكني يحصل على CAPTCHA؟
لأن سمعة IP هي واحدة فقط من أربع طبقات. إذا كانت بصمة TLS/HTTP تقول "سكربت"، أو فشل المتصفح أو يفتقر إلى تحدي JavaScript، أو كان السلوك آليًا، تكون النتيجة سيئة بغض النظر عن الـ IP.
هل تشارك أنظمة مكافحة البوتات البيانات بين المواقع؟
داخل البائع، نعم: الـ IP أو البصمة التي تم الإبلاغ عنها على موقع أحد العملاء تزيد من خطورتها على مواقع العملاء الآخرين. لهذا السبب قد يكون أداء مجموعة بروكسيات مستخدمة بكثافة ضد هدف محمي بواسطة Cloudflare سيئًا على أهداف أخرى محمية بواسطة Cloudflare غير مرتبطة.
هل يمكن لمكتبات HTTP العادية اجتياز تحديات JavaScript؟
لا. تتطلب التحديات تنفيذ JavaScript في بيئة تشبه المتصفح. الخيارات هي متصفح آلي حقيقي، أو خدمة حل تشغل التحدي نيابة عنك وتعيد ملف تعريف الارتباط/الرمز المميز الناتج — والذي له تكلفة ومخاطر اكتشاف خاصة به.
ما الفرق بين التحدي وCAPTCHA؟
التحدي غالبًا ما يكون غير مرئي — حمل عمل JavaScript أو إثبات يُكمله المتصفح تلقائيًا. CAPTCHA هو لغز مرئي للبشر، يظهر عندما تكون النتيجة سيئة بما يكفي ليريد النظام دليلًا صريحًا.
هل من الممكن أن تكون غير قابل للاكتشاف تمامًا؟
ليس كضمان. الاكتشاف احتمالي ويقوم البائعون بالتحديث باستمرار. ما يمكن تحقيقه هو الاتساق عبر جميع الطبقات الأربع بالإضافة إلى سلوك بشري الشكل، مما يبقي النتيجة في نطاق "السماح" معظم الوقت. أي شخص يعد بعدم قابلية الاكتشاف من البروكسي وحده يبيع فقط الطبقة 1.