شرح البروكسي الدوّار: كيف يعمل تدوير IP ومتى يعطّل مهمتك

كان سكربت لمراقبة الأسعار يفحص مئات صفحات المنتجات كل ليلة بلا مشكلات لأشهر. ثم زاد التكرار وأُضيف متجر ثانٍ، فامتلأت السجلات بردود 429 وصفحات CAPTCHA. نصيحة المنتديات المعتادة هي البروكسي الدوّار. فكرة أن كثرة العناوين تقلّل الحظر صحيحة إلى النصف فقط.

يرسل البروكسي الطلبات عبر عناوين متغيرة خلف بوابة ثابتة، فيوزع الحركة لتبقى تحت الحد المحسوب لكل IP. لكن العنوان قد يتغير أثناء الدخول، وغالبًا لا تستمر الجلسة المصادَق عليها. التدوير يحل مشكلة ويخلق أخرى.

النسخة المختصرة

• البروكسي الدوّار بوابة واحدة بمضيف ومنفذ، تمرّر الطلبات عبر عنوان من مخزون، وتحدد قاعدة التدوير وقت تغييره.
• التدوير لكل طلب مناسب لجلب الصفحات العامة دون حالة. للدخول والسلال، فضّل جلسة ثابتة أو بروكسي ثابتًا، خصوصًا إذا فحص الموقع استمرارية IP.
• قد يعمل التدوير كما ضُبط ويفشل المخزون لأن العملاء الآخرين يستهلكون سمعة العناوين المشتركة. حداثة العناوين وقلة مشاركتها أهم من حجم المخزون لتوقع النجاح.
• لا يفيد التدوير أمام حد مرتبط بحساب أو رمز أو ملف ارتباط. للمهام الصغيرة، أبطئ أولًا واحترم مدة الانتظار في Retry-After.

ما البروكسي الدوّار؟

تمرّر البوابة الطلب عبر عنوان مختار. تحدد القاعدة تغييره لكل طلب أو بوقت أو لكل جلسة. المضيف والمنفذ ثابتان، والبوابة تختار ما تراه الوجهة.

تتبّع طلبًا عبر البوابة:

1. يرسل العميل دائمًا إلى المضيف والمنفذ نفسيهما.
2. تطبق البوابة القاعدة وتختار عنوان خروج.
3. يغادر الطلب من ذلك العنوان إلى الموقع المقصود.
4. ترى الوجهة عنوان الخروج. يبقى عنوانك مخفيًا ما لم تمرره البوابة في ترويسة مثل X-Forwarded-For.

يدير المزوّد المخزون وفحوص السلامة والتحويل عند الأعطال؛ لا يعرف السكربت إلا المضيف والمنفذ. هذه السهولة تفسر الخدمة. تشغيل بروكسي خاص لا يمنح تدويرًا مجانيًا: يعطي عادةً عنوان خروج ثابتًا واحدًا؛ وما تدفع مقابله هو صيانة المخزون.

يسمّي المزوّدون البوابة مع المخزون بروكسي backconnect. يذكر دليل MDN لخوادم البروكسي البوابة اسمًا أبسط للبروكسي الأمامي. كون العناوين سكنية أو لمراكز بيانات أو محمولة مستقل عن تكرار تغييرها.

ما الذي يحدد وقت تغيير IP؟

القاعدة والمزوّد يحددان: لكل طلب أو اتصال، أو نافذة ثابتة، أو أمر صريح. قد يغيّر العميل أو المدير العنوان قبل إعادة طلب فاشل أو محظور. تحقق من معنى «لكل طلب»: قد تتشارك طلبات HTTPS نفقًا وIP واحدًا. البوابة التي تمرّر HTTPS مشفرًا لا تقرأ عادةً رمز استجابة الوجهة لتبدأ التدوير بنفسها.

الجدول قرار توزيع. الانتشار يبقي كل IP تحت العتبة، والاستمرارية تتيح معرفة زائر واحد. التدوير لكل طلب يفضّل الانتشار بالكامل. التدوير عند الفشل يبدو حلًا وسطًا متينًا، لكنه يخفي تكلفته: تظهر السجلات نجاح الإعادة حتى يفشل كل شيء. الجلسة الثابتة تعكس المقايضة وتحتفظ بعنوان لنافذة زمنية.

كيف تختلف الجلسة الثابتة عن التدوير والبروكسي الثابت؟

تحجز الجلسة الثابتة عنوانًا مؤقتًا ليبدو التسلسل كزائر واحد، ثم تطلقه. يحتفظ البروكسي الثابت بعنوان ما دمت تحتفظ به. التدوير لكل طلب لا يحجز شيئًا. الاختيار يتوقف على حاجة الموقع لتذكرك بين الطلبات.

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

متى يعطّل التدوير المهمة؟

قد يقطع تغيير العنوان أثناء الدخول و2FA والسلة والدفع والنماذج متعددة الخطوات المسار. لا يبطل ملف الارتباط تلقائيًا، لكن ربط الجلسة بالعنوان أو فحص تغير الشبكة لمكافحة الاحتيال قد يسبب خروجًا أو تحديًا جديدًا أو إشارة تحذير.

أراه موقعًا يؤدي عمله، لا يستهدف البروكسي. يدّعي ملف الارتباط أنه المتصفح نفسه قبل دقيقة، والعنوان دليل قابل للفحص. تغير الشبكة وسط جلسة مصادَق عليها يشبه إعادة استخدام ملف مسروق في مكان آخر، ما تبحث عنه أنظمة الاحتيال. الخروج وطلب 2FA استجابتان متناسبتان.

تشرح إرشادات OWASP لإدارة الجلسات فحص تغير IP وUser-Agent. بحسب الضوابط، قد يطلق تغير غير متوقع تنبيهًا أو ينهي الجلسة.

هل يجب أن يتذكرك الموقع بين الطلبات؟ إن نعم، احتفظ بعنوان للمسار؛ وإلا دوّره. فحص الأسعار العامة ليلًا لا يحتاج ذلك. الدخول للوحة لتصدير تقارير يحتاج عنوانًا واحدًا من البداية للنهاية.

نصيحة عملية: افصل الأحمال المختلطة: مخزون دوّار للبيانات دون حالة، وعنوان جلسة ثابت أو بروكسي ثابت للدخول والعمل المصادَق عليه. الاحتياجات المتعارضة لا تشترك في قاعدة.

لماذا يتوقف المخزون بعد أيام؟

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

المخزون مورد مشترك محدود؛ يستهلك كل عميل سمعته لدى المواقع. استخدام آخرين للعناوين نفسها مع أهدافك يكلّفك CAPTCHA وحظرًا. في الدعم رأيت السمعة كنظام مواقع وقوائم حظر يستجيب للنشاط المرصود.

الحجم سهل الإعلان لكنه يتنبأ بأقل مما يبدو. يعتمد النجاح على:

• آخر استخدام لنفس الهدف: عنوان استخدمه عميل قبل ساعة محسوب أصلًا.
• عدد المشاركين: كثرة المهام تستهلك العنوان أسرع.
• تنوع الشبكات: تجمع العناوين في نطاقات قليلة يسمح بحظرها معًا.
• الإشارات السابقة: المخزون الذي يبقي عناوين مسيئة يواصل توزيعها.

قد يكون المخزون الكبير كثير الاستخدام أسوأ من صغير بعناوين جديدة لأهدافك. قارن النجاح مع الوقت؛ اختبار أول ناجح لا يثبت أداءً مستمرًا.

هل تحتاج بروكسي دوّارًا أصلًا؟

قد يوزع الطلبات تحت حدود IP، لكنه لا يستبدل احترام الحدود وتعليمات الإعادة. بحسب مرجع MDN للحالة 429، الحدود غالبًا حسب IP، وقد تتبع مستخدمًا أو تطبيقًا عند المصادقة أو وجود ملف ارتباط. حد الحساب يتجاهل IP الجديدة؛ على المهمة الصغيرة احترام Retry-After أولًا.

المعيار هو RFC 6585 الذي عرّف الحالة 429. يسمح بترويسة Retry-After لتحديد الانتظار، دون فرض تحديد المستخدم أو العد. يذكر مثالًا ببيانات المصادقة أو ملف ارتباط ذي حالة.

ثلاث حالات لشراء خاطئ: حد حساب أو رمز API أو ملف ارتباط، حيث تستهلك كل العناوين الحصة نفسها ويستمر 429؛ مهمة صغيرة تستطيع مجانًا توزيع مئات الصفحات الليلية، وانتظار Retry-After والإعادة بتراجع أُسّي؛ وعمل مسجل الدخول يحتاج هوية وعنوانًا ثابتين.

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

قبل الدفع، اقرأ الوثائق والترويسات. إذا تلقت طلبات مصادَق عليها قابلة للمقارنة 429 ونجحت المجهولة من العنوان نفسه، فهذا يرجّح حد الحساب أو المصادقة ولا يثبته. فشل الاثنين قد يعني حد IP أو مورد أو خادم كامل. حافظ على نقطة نهاية ومعدل قابلين للمقارنة واحترم Retry-After قبل إعادة الاختبار.

الأسئلة الشائعة