ما هو بروكسي rotating؟
بروكسي rotating — أو ما يُعرف كثيرًا باسم البروكسي الدوّار أو البروكسي الذي يغيّر الـ IP تلقائيًا — هو نظام يُخرج طلباتك بالتناوب عبر عناوين مختلفة من تجمّع واسع بدل IP ثابت واحد. أنت تعرّف في تطبيقك نقطة اتصال واحدة (gateway)؛ والبنية التحتية هي التي تقرّر أي طلب يخرج من أي عنوان.
أكبر مكسب في هذه البنية هو البساطة التشغيلية. فبدلًا من شراء مئات العناوين وإدارة قوائمها وصحتها وحالات حظرها، تصل إلى ملايين العناوين بتعريف بروكسي من سطر واحد. يُنقل التعقيد إلى البنية التحتية؛ وتركّز أنت على البيانات وحدها.
بنية Backconnect: خلف الكواليس
قلب بروكسي rotating هو خادم backconnect (gateway) . والعنوان الذي تعرّفه في تطبيقك — مثل gw.freeproxy.tr:7777 — ليس IP بل بوابة. كل اتصال لك يدخل من هذه البوابة ويخرج إلى الإنترنت بعنوان مناسب من تجمّع الـ IP الضخم خلفها.
اختيار الـ IP ليس عشوائيًا. فالبنية التحتية تأخذ في الحسبان صحة العنوان وما إذا كان قد زار الهدف مؤخرًا وقاعدة التدوير التي حدّدتها. وطبقة الاختيار الذكية هذه تعفيك من مئات أسطر إدارة الأخطاء في شيفرتك.
منطق تغيير الـ IP — ثلاثة أوضاع
التدوير على أساس الطلب (Request)
يخرج كل طلب HTTP بعنوان IP مختلف من التجمّع. وفي مسح بألف صفحة يرى الموقع الهدف ألف زائر مختلف؛ ويصبح حدّ الطلبات لكل IP بلا معنى عمليًا. وهو الوضع الافتراضي لأعمال web scraping واسعة النطاق. وهو مثالي عند سحب صفحات مستقلة لا علاقة لإحداها بالأخرى.
التدوير على أساس المدة
يتغيّر الـ IP تلقائيًا ضمن الفاصل الذي تحدّده (كل 5 دقائق مثلًا). وهو مناسب للتدفقات التي تتضمن تنقلًا بين الصفحات لكنها لا تتطلب جلسة طويلة. ويفيد في العمليات متوسطة الطول مثل تصفّح فئة والاطلاع على بضعة منتجات.
Sticky Session
تضيف معرّف session إلى معامل الاتصال؛ ويقع المعرّف نفسه على الـ IP نفسه طوال 1-30 دقيقة. وتُنجَز بهذا الوضع تدفقات تسجيل الدخول وعمليات السلة والنماذج متعددة الخطوات. تفصيل حاسم: امنح كل مهمة معرّف session مختلفًا. فتحميل كل شيء على IP واحد بمعرّف واحد يُفرِغ التدوير من غرضه كله.
| نوع المهمة | الوضع المقترح |
| مسح قوائم المنتجات/الفئات | على أساس الطلب |
| تسجيل دخول + سحب بيانات | Sticky |
| تصفّح متعدد الصفحات | على أساس المدة |
| فحص جماعي لروابط URL | على أساس الطلب |
إدارة ذكية للتجمّع
البنية التحتية الجيدة لـ rotating لا تختار الـ IP عشوائيًا؛ فخلفها طبقة صحّة تعمل باستمرار:
- تُسحب تلقائيًا من التدوير العناوين التي تتباطأ أو التي تضع الأهداف عليها علامة.
- تُعاد الطلبات الفاشلة تلقائيًا عبر IP مختلف (retry ذكي).
- يُفضَّل حسب نطاق الهدف عنوان IP "لم يزر ذلك الهدف مؤخرًا"؛ فيُمنع تشكّل الأنماط.
- تُراقَب صحة التجمّع لحظيًا؛ ويُحافَظ على معدّل نجاح عام مرتفع.
مزاياه في جانب الـ scraping
بروكسي rotating هو العمود الفقري لجمع البيانات على نطاق واسع. ومزاياه:
- طلبات أقل لكل IP: يقع على كل IP عدد طلبات دون حدّ تسامح الهدف؛ فينخفض خطر الحظر إلى أدنى مستوى.
- تزامن بلا حدود: يمكنك إرسال آلاف الطلبات بالتوازي؛ ولا يوجد حدّ للاتصالات.
- retry تلقائي: يُعاد الطلب الفاشل عبر IP مختلف؛ ولا تلزم إدارة أخطاء يدوية.
- لا إدارة قوائم: تختفي الأعمال الروتينية مثل تنقية العناوين الميتة وإدارة الحظر.
أي تجمّع؟ residential أم mobile؟
التدوير آلية؛ أما تجمّع الـ IP تحته فهو خيار منفصل. وفهم هذا التمييز مهم:
- Rotating Residential: تجمّع residential يعطي أوسع تنوّع (10M+ عنوان) وهو القياسي لمعظم المهام. ويحقق نجاحًا عاليًا على الأهداف المحمية.
- Rotating Mobile: تجمّع mobile يقدّم أعلى درجة ثقة؛ ويدخل حيّز العمل في الأهداف الأشد حماية.
- Rotating Datacenter: أسرع الخيارات وأرخصها على الأهداف غير المحمية؛ وأثره محدود أمام الحمايات العدوانية.
تختار حسب مستوى حماية هدفك. وإذا ترددت فالبدء بـ residential خيار افتراضي آمن.
الأتمتة وتكامل الأدوات
تعمل Scrapy وPuppeteer وPlaywright وSelenium وجميع عملاء HTTP بتعريف gateway واحد. بروكسي الأتمتة — في هذه الصفحة تجد أمثلة تهيئة حسب كل أداة.
| البيئة | الاستخدام |
| curl | curl --proxy gw.freeproxy.tr:7777 --proxy-user user:pass https://hedef |
| Python requests | proxies={"https":"http://user:pass@gw.freeproxy.tr:7777"} |
| Scrapy | تدوير تلقائي في كل طلب؛ والتحكم في الـ session عبر middleware |
| Playwright | معامل proxy في الـ context + معرّف session |
أنماط الاستخدام الصحيحة
- نمط القوائم + التفاصيل: اسحب صفحات الفئات على أساس الطلب، والجلسات المؤدية إلى تفاصيل المنتج بوضع sticky.
- ضبط الوتيرة: التدوير يحميك من الحدود، لكن الوتيرة المحترمة للهدف تبقى مسؤوليتك. استخدم تأخيرات عشوائية.
- راقب مقياس النجاح: سجّل نسبة 403/429 لديك؛ فارتفاعها إشارة إلى الحاجة لضبط التجمّع أو الوتيرة.
- افصل معرّفات الـ session: معرّف منفصل لكل مسار تنفيذ؛ فيُحفظ التوازي وتبقى الجلسات متسقة.
منطق التسعير
باقات rotating على أساس GB. وتُخصم جميع أوضاع التدوير (الطلب، المدة، sticky) من عدّاد الحركة نفسه؛ والـ GB غير المستخدم يُرحَّل إلى الشهر التالي. وبما أن التزامن غير محدود فأنت تدفع على أساس "كم من البيانات" لا "كم اتصالًا" — وهذا نموذج يمكن التنبؤ به للعمليات المتوسّعة. وكلما كبر الحجم انخفض سعر وحدة الـ GB.
مسائل تقنية شائعة
- هل يتكرر الـ IP نفسه؟ بسبب حجم التجمّع فإن الاحتمال ضئيل جدًا على المدى القصير؛ وإذا لزم تفرّد قاطع فالتحكم يتم عبر معاملات الـ session.
- هل الـ gateway نقطة فشل وحيدة؟ لا؛ فطبقة الـ gateway مكرّرة، وإذا سقطت عقدة تُنقل الحركة تلقائيًا.
- هل يمكنني اختيار الدولة؟ نعم؛ تُغيَّر معاملات الاستهداف على أساس كل طلب، وتصل إلى 150+ دولة بحساب واحد.
نصيحة: إذا أردت تجربة النظام الدوّار قبل الشراء فيمكنك اختبار تدفّق طلباتك على عناوين البروكسي المجانية المحدّثة . وبما أن العناوين المجانية متقلّبة يُنصح بالتجمّع المدفوع لأعمال الإنتاج؛ لكن تجربة منطق التدوير يدويًا هي أفضل طريقة لفهم ما يفعله التدوير التلقائي.