كشط الويب على نطاق واسع: متى ولماذا نستخدم البروكسيات العامة

تدوير البروكسي هو عكاز، وليس حلاً. تفشل معظم عمليات الكشط لأنها تتعامل مع عناوين IP كالإشارة الوحيدة التي تقيسها أنظمة مكافحة البوتات. الحقيقة أن مديري البوتات الحديثين — Akamai Bot Manager وCloudflare Turnstile وDatadome — يبصمون أكثر بكثير من مجرد عنوان IP المصدر. مجموعة متناوبة من البروكسيات العامة المجانية لا تشتري لك شيئاً تقريباً ضد هذه الأنظمة، وغالباً ما تجعل الأمور أسوأ.

وهم تدوير IP

عندما تدور عناوين IP في كل طلب، فإنك تعلن عن نفسك ككاشط. أنماط التصفح البشري تُظهر جلسات ثابتة — عنوان IP واحد لدقائق أو ساعات، بصمات متصفح متسقة، وفواصل زمنية متوقعة بين الطلبات. أدوات مثل requests مع كائن Session وقائمة بروكسيات متناوبة تكسر كل هذه الإشارات. يمكن لرأس X-Akamai-Device-Fingerprint من Akamai وارتباط cf-request-id من Cloudflare ربط الطلبات القادمة من عناوين IP مختلفة عندما تبقى معلمات TLS وإعدادات HTTP/2 والتوقيت متطابقة. يتحقق تحدّي JavaScript من Datadome من وجود آثار للمتصفحات غير المرئية (headless) التي تبقى حتى بعد تغيير البروكسي. تدوير عناوين IP دون تدوير بصمة العميل الكاملة يشبه تغيير لوحة سيارتك مع قيادة نفس السيارة — كاميرات المرور ستظل تتعرف عليك.

بالنسبة للكشط منخفض المعدل ومنخفض الحجم ضد المواقع التي تستخدم فقط تحديد معدل بسيط قائم على IP (مثل حد 10 طلبات في الدقيقة بدون تحديات JavaScript)، غالباً ما يكفي عنوان IP سكني واحد. لقد قمت بتشغيل كاشطات لسنوات ضد بوابات البيانات الحكومية وواجهات برمجة التطبيقات العامة باستخدام عنوان IP ثابت واحد وtime.sleep(2) مهذب. لا حاجة لبروكسي. القاعدة بسيطة: إذا كان الموقع لا يقدم صفحة تحدٍ أو CAPTCHA بعد 50 طلباً، فأنت لا تحتاج إلى تدوير.

ما وراء عنوان IP: البصمات

تجمّع أنظمة مكافحة البوتات الآن عشرات الإشارات لكل طلب. سلسلة User-Agent سهلة التزييف، لكن ترتيب Accept-Language وSec-CH-UA وConnection وAccept-Encoding ليس كذلك. والأهم من ذلك، بصمة TLS — الموحدة في تجزئة JA3 (انظر JA3) — تحدد مكتبة العميل من خلال ترتيب مجموعات التشفير وقائمة إضافات TLS. تنتج مكتبة requests في Python (عبر urllib3) تجزئة JA3 تختلف عن Chrome 124. يتحقق كل من Cloudflare Turnstile وDatadome من JA3. تدوير عناوين IP مع الحفاظ على نفس مجموعة TLS يجعل كل طلب يبدو وكأنه نفس العميل الآلي، لكنه يتنقل بين عقد الخروج. تزيد البروكسيات المجانية من هذا الأمر لأنها غالباً ما تشغل إصدارات قديمة من OpenSSL أو تستخدم تكوينات TLS شبيهة بالبوتات تم إدراجها بالفعل في القائمة السوداء.

بصمة HTTP/2 تذهب أبعد من ذلك. تشكل إطار SETTINGS وقيم تحديث النافذة ومعلمات التزامن في التدفق "بصمة HTTP/2" فريدة يتتبعها Akamai Bot Manager عبر الجلسات. مجموعة بروكسيات متناوبة لا تدور أيضاً تنفيذ HTTP/2 يسهل تجميعها. الطريقة الوحيدة لتجنب هذه الفحوصات هي استخدام محرك متصفح حقيقي (Puppeteer، Playwright) أو مجموعة TLS/HTTP مصممة بعناية تحاكي إصدار متصفح معين — وحتى ذلك الحين، تحتاج إلى الحفاظ على نفس البصمة عبر الطلبات من جلسة معينة.

اقتصاديات مجموعات البروكسيات العامة المجانية

قوائم البروكسيات العامة المجانية لديها معدل فشل يتراوح بين 60–80 بالمئة في اختباراتي. معظم البروكسيات إما ميتة عند الوصول، أو مقيدة من قبل المضيف، أو تم وضع علامة عليها بالفعل من قبل مديري البوتات الكبار. متوسط عمر بروكسي SOCKS5 مجاني مأخوذ من دليل عام أقل من 15 دقيقة. الحفاظ على مجموعة متناوبة من 500 بروكسي يعني أنك تحرق آلاف عناوين IP في الساعة، و80% من طلباتك إما تنتهي بانتهاء المهلة أو تعيد 403. النطاق الترددي غير موثوق، وارتفاعات زمن الوصول شائعة، والعديد من البروكسيات المجانية تحقن إعلانات أو تعدل نصوص الاستجابة. شبكات البروكسيات السكنية المدفوعة (مثل Bright Data، Oxylabs) تقدم معدلات نجاح تزيد عن 95% وخيارات جلسات ثابتة، لكن بتكلفة تتراوح بين 10–20 دولاراً لكل غيغابايت. على نطاق واسع، الرياضيات تفضل البروكسيات السكنية فقط عندما تحتاج إلى تجاوز حظر قائم على IP لأهداف عالية القيمة. لكل شيء آخر، عنوان IP نظيف واحد مع وتيرة طلبات مناسبة يتفوق على مجموعة مجانية فوضوية.

عندما يعمل التدوير فعلاً

تدوير البروكسي فعال ضد تهديد واحد محدد: حدود المعدل القائمة على IP والتي تعاد لكل عنوان IP. إذا كان الموقع يستخدم فحص X-Forwarded-For بسيطاً أو دلو رمز لكل IP، فإن التدوير بعد كل طلب يتجاوز الحد. هذا شائع في مواقع التجارة الإلكترونية الصغيرة وواجهات برمجة التطبيقات القديمة التي لم تحدث كشف البوتات الخاص بها. في هذه الحالات، حتى مجموعة البروكسيات المجانية تعمل — ولكن فقط إذا قمت بتنفيذ منطق إعادة المحاولة الذي يتجاهل البروكسيات الفاشلة ويدور عبر بروكسيات جديدة بسرعة.

هذا مثال بسيط بلغة Python باستخدام requests وحلقة إعادة محاولة مع التدوير. يفترض قائمة بعناوين URL للبروكسيات في proxy_list وهدف url:

import requests
from itertools import cycle

proxy_pool = cycle(proxy_list)
max_retries = 5

for attempt in range(max_retries):
    proxy = next(proxy_pool)
    try:
        resp = requests.get(
            url,
            proxies={"http": proxy, "https": proxy},
            timeout=10,
            headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."}
        )
        if resp.status_code == 200:
            break
    except (requests.ConnectionError, requests.Timeout):
        continue
else:
    raise RuntimeError("All proxies failed")

يعمل هذا النمط فقط عندما يكون كشف الموقع قائماً على IP بحت. أضف time.sleep(random.uniform(1,3)) بين الطلبات لمحاكاة توقيت البشر. بالنسبة للمواقع التي تشغل Turnstile أو Datadome، سيفشل هذا الكود في كل مرة — ستعيد صفحة التحدي 403 أو CAPTCHA بغض النظر عن البروكسي. في هذه الحالات، تحتاج إلى متصفح غير مرئي (headless) مع بصمة حقيقية، وليس قائمة بروكسيات متناوبة.

الجلسات الثابتة — الحفاظ على نفس IP لمجموعة من الطلبات ذات الصلة — غالباً ما تكون أكثر فعالية من التدوير لكل طلب. تتوقع العديد من مواقع التجارة الإلكترونية عنوان IP واحد لجلسة تصفح (مثل إضافة عناصر إلى سلة التسوق، إتمام الشراء). التدوير في منتصف الجلسة يؤدي إلى تشغيل أعلام الاحتيال. استخدم مجموعة من البروكسيات ولكن خصص عنوان IP واحد لكل جلسة، وليس لكل طلب. نادراً ما تدعم البروكسيات المجانية الجلسات الثابتة لأن نفس IP يُستخدم من قبل عدة مستخدمين؛ سترى تلوثاً متبادلاً لبيانات الجلسة. تقدم البروكسيات السكنية المدفوعة فترات جلسات ثابتة (5–30 دقيقة) تتوافق مع سلوك التصفح الطبيعي.

اختر التدوير فقط عندما تفهم مجموعة كشف الهدف. اختبر أولاً باستخدام عنوان IP واحد. أضف التدوير فقط إذا وصلت إلى حد معدل. ولا تعتمد أبداً على البروكسيات المجانية للإنتاج — فمعدل فشلها سيكلفك وقتاً هندسياً وبيانات مفقودة أكثر من خطة سكنية رخيصة.