تدوير البروكسي مع الطلبات المتزامنة: سجل زمني يحدد عنوان الخروج لكل طلب

المشكلة التي لا يحلها اختبار عنوان IP مرة واحدة

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

ابدأ بتعريف العقد مع المزود

قبل كتابة أي سكربت، اقرأ سياسة الجلسة: هل التدوير تلقائي كل مدة؟ هل هناك رمز Session ID؟ هل يوجد أمر صريح لتغيير العنوان؟ وهل تُحسب الاتصالات المتوازية ضمن جلسة واحدة أم عدة جلسات؟ لا تفترض أن كلمة rotating تعني عنوانًا جديدًا لكل طلب أو أن sticky تعني عنوانًا أبديًا. سجّل نوع البروكسي HTTP أو SOCKS، والمنطقة المطلوبة، وطريقة الاعتماد، وحدود التزامن المسموح بها. اجعل الاختبار ضمن خدمات ووجهات تملك حق استخدامها؛ تغيير IP لا يلغي شروط المواقع ولا ضوابط الوصول.

صمّم معرف ارتباط لا يكشف أسرارًا

امنح كل طلب requestId عشوائيًا لا يحتوي اسم حساب أو بيانات عميل، وسجّل attemptId إذا أُعيدت المحاولة. أضف وقت البداية والنهاية بصيغة UTC، ومعرف جلسة اختبار غير حساس، والوجهة، وحالة HTTP، ومدة الاتصال، وعنوان الخروج الذي أعادته خدمة قياس موثوقة. لا تضع اسم المستخدم وكلمة المرور أو رابط البروكسي كاملًا في السجل. إذا استعملت معرفًا في عنوان URL، فتذكر أن الخادم قد يسجله؛ استخدم قيمة قصيرة عديمة الدلالة. اربط النتائج بمعرف التجربة بدل جمع بيانات تصفح حقيقية.

فرّق بين الطلب والاتصال والجلسة

قد ترسل عدة طلبات HTTP فوق اتصال واحد، أو تنشئ اتصالات متوازية جديدة، أو تستخدم HTTP/2 متعدد التدفقات، وكل حالة تختلف عن الأخرى. سجّل ما إذا كان العميل يعيد استخدام الاتصال، لأن تبديل العنوان قد يحدث عند إنشاء اتصال جديد لا في منتصف اتصال قائم. افصل أيضًا Session ID الخاص بالمزود عن كوكيز موقع الوجهة؛ فهما آليتان مستقلتان. إذا لم يكشف العميل تفاصيل إعادة الاستخدام، اذكر أن الاستنتاج متعلق بالطلبات المرصودة فقط. لا تفسر ثبات عنوان IP بين طلبين بأنه فشل تدوير دون معرفة السياسة المتفق عليها.

اختر وجهتين مستقلتين وبيئة ضابطة

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

اختبار التسلسل البطيء أولًا

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

ثم اختبر التزامن المنخفض بصورة آمنة

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

تفسير التغيير أثناء إعادة المحاولة

قد يفشل طلب أول بسبب مهلة، ثم تنجح إعادة المحاولة من عنوان آخر. إذا حفظت النتيجة النهائية فقط ستفقد الحدث الأهم. سجّل كل محاولة مستقلة مع parentRequestId، وسبب الإعادة، وعنوان الخروج إن أمكن، ولا تجمع زمن المحاولات في رقم واحد دون توضيح. احذر أن طلبًا من نوع POST قد ينفذ أثرًا على الخادم رغم انقطاع الرد؛ استخدم واجهة اختبار عديمة الأثر أو مفتاح idempotency مناسبًا. الهدف قياس مسار الشبكة، لا توليد معاملات متكررة أو التأثير على خدمات حقيقية.

اعرف حدود ما يستطيع خادم القياس إثباته

الخادم يستطيع عادة رؤية عنوان مصدر الاتصال الوارد إليه، لكن وجود CDN أو Reverse Proxy أو ترويسات وسيطة قد يجعل القراءة مختلفة. تأكد من مصدر حقل IP، ولا تثق عميانيًا بترويسة X-Forwarded-For يرسلها العميل؛ يجب ضبط قائمة الوسطاء الموثوقين. قد يرى خادم القياس عنوان خروج NAT مشتركًا بين مستخدمين. كذلك لا يمكن استنتاج عنوان الجهاز الأصلي أو تفاصيل سلسلة البروكسي كاملة من النتيجة. وثّق حدود الرؤية حتى لا يتحول تقرير القياس إلى ادعاء عن هوية المستخدم.

جدول يفرق النتائج المتشابهة

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

مقاييس مفيدة دون مبالغة إحصائية

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

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

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

الخصوصية والسلامة أثناء التسجيل

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

خطة تنفيذ ومراجع

ابدأ بمجموعة ضابطة مباشرة، ثم تسلسل منخفض التواتر، ثم ثلاث اتصالات متوازية، ثم اختبار إعادة محاولة آمن، واحفظ جدول النتائج بصيغة CSV لا يحتوي أسرارًا. للمقارنة المنضبطة قبل وبعد تغيير البروكسي راجع إيجي تاج: https://egytag.com/ar/articles/proxy-switch-paired-benchmark-before-after-confounders-2026 . توثق curl خيارات البروكسي والتوقيت في https://curl.se/docs/manpage.html ، ويشرح RFC 9110 مفاهيم الطلب والاتصال والوسطاء في https://www.rfc-editor.org/rfc/rfc9110.html . لا تعطي هذه المراجع ضمانًا لسياسة تدوير مزود بعينه؛ تحقق من عقده الفعلي.