اختبار سرعة البروكسي: دليل عملي لعام 2026

لقد اجتاز البروكسي الخاص بك الفحص. لقد أعاد عنوان IP. لقد قام حتى بتحميل صفحة.

ثم بدأت الأتمتة الخاصة بك في الفشل.

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

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

لماذا اختبار سرعة البروكسي الخاص بك ربما يكون خاطئًا

لا يزال من الشائع اختبار البروكسيات كما لو كانت سؤالًا ثنائيًا. يعمل أو لا يعمل. هذه العقلية قديمة.

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

علامة تحقق خضراء ليست نتيجة أداء

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

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

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

قاعدة عملية: إذا كانت تطبيقك يقوم بأكثر من طلب واحد لكل إجراء مستخدم، فإن اختبار سرعة البروكسي لطلب واحد ضحل جدًا.

تجعل البروكسيات المحمولة الاختبارات الضعيفة تبدو أفضل مما هي عليه

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

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

الهدف الخاطئ للاختبار يخلق ثقة زائفة

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

اختبار مفيد يعكس الوجهة والسلوك:

• نفس المنطقة مثل منصة الهدف أو صفحة الهبوط
• نفس البروتوكول الذي يستخدمه تطبيقك
• نفس نمط الطلب الذي تنتجه الأتمتة الخاصة بك
• نفس توقيت الجلسة الذي تتوقعه في الإنتاج

عندما تتعامل الفرق مع ضمان جودة البروكسي كمنضومة مستمرة بدلاً من فحص لمرة واحدة، فإنها تتوقف عن طرح سؤال "هل هذا البروكسي حي؟" وتبدأ في طرح سؤال "هل هذا البروكسي مناسب لهذه المهمة؟"

هذه هي الفجوة بين قائمة البروكسيات ونظام البروكسيات.

اختيار مقاييس الأداء الرئيسية الخاصة بك

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

زمن الاستجابة للإجراءات التفاعلية

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

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

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

تناسب جيد للاختبار القائم على زمن الاستجابة:

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

الإنتاجية للعمل الثقيل بالحمولة

تقيس الإنتاجية مقدار البيانات التي يمكن أن يحملها البروكسي بمرور الوقت. هذا مهم، ولكن بشكل أساسي عندما تكون حجم الحمولة هو المشكلة.

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

يمكن أن يعمل البروكسي الذي لديه إنتاجية معتدلة بشكل جيد أيضًا للأتمتة المعتمدة على الجلسات إذا كانت استجاباته ثابتة وإعداد اتصاله نظيفًا.

زمن الاتصال ومعدل النجاح للواقع

يجب أن تعطي معظم الاختبارات الجادة الأولوية لجوانب مثل الاتصالات الموثوقة وتسلسل الطلبات الكامل. السرعة الخام لا تخبرك ما إذا كان البروكسي يتصل بشكل موثوق أو يكمل تسلسل الطلبات بالكامل دون انقطاع.

إطار عملي:

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

مطابقة المقياس مع المهمة

لا تعامل كل سير عمل بنفس الطريقة. يبدأ معيار البروكسي النظيف مع الحمل.

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

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

طرق سطر الأوامر العملية للاختبار الدقيق

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

ابدأ باستخدام curl وسجل الحقول الصحيحة

curl هو الخيار الصحيح للمرور الأول لأنه يكشف عن التوقيتات التي تهم ويجعل الاختبار سهل التكرار.

استخدم أمرًا مثل هذا:

curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} starttransfer=%{time_starttransfer} total=%{time_total} size=%{size_download} speed=%{speed_download}\n' \
  https://TARGET_URL

تجيب هذه الحقول على أسئلة مختلفة:

• time_connect يظهر سرعة مصافحة البروكسي.
• time_starttransfer يظهر انتظار الخادم بالإضافة إلى أي تأخير تم إدخاله بواسطة المسار.
• time_total يظهر التكلفة الكاملة للطلب.
• speed_download يعطي قراءة تقريبية لأداء النقل لتلك الاستجابة.
• http_code يظهر ما إذا كان الطلب قد اكتمل بطريقة قابلة للاستخدام.

بالنسبة لـ SOCKS5، قم بتبديل علامة البروكسي:

curl --proxy socks5h://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
  https://TARGET_URL

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

قم بتشغيل الطلبات المتكررة بدلاً من الطلقات الفردية

يثبت طلب واحد تقريبًا لا شيء. تبدأ عشرة طلبات في إظهار السلوك.

for i in $(seq 1 10); do
  curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
    -s -o /dev/null \
    --connect-timeout 15 \
    -w 'run='$i' code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
    https://TARGET_URL
done

اقرأ مجموعة التشغيل كعامل، وليس كجدول مرجعي.

• هل تبقى أوقات الاتصال في نفس النطاق؟
• هل تتوقف بعض الطلبات بالقرب من وقت الانتظار؟
• هل تتقلب رموز الحالة خلال السلسلة؟
• هل تنخفض الأداء بعد التدوير أو بعد عدة ضربات من نفس المنفذ؟

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

أضف التزامن بحذر

تغير الحمل القصة بسرعة. قد يصبح البروكسي الذي يتعامل مع طلب واحد بشكل نظيف غير مستقر بمجرد دفع حركة المرور المتوازية من خلاله.

نمط بسيط في الشل:

seq 5 | xargs -I{} -P 5 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

ثم قم بزيادة التوازي:

seq 10 | xargs -I{} -P 10 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

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

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

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

اختبر مسار الطلب الحقيقي، وليس فقط عنوان URL ثابت

يعد طلب GET العادي مفيدًا للتوقيت. لكنه ليس كافيًا لسير العمل التي تسجل الدخول، تتبع عمليات إعادة التوجيه، تحميل واجهات برمجة التطبيقات، أو إعادة استخدام ملفات تعريف الارتباط.

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

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

استخدم اختبارًا على نمط iperf فقط لسؤال ضيق

تجيب اختبارات عرض النطاق الترددي على مستوى منخفض على سؤال ضيق واحد. هل المسار النقل مقيد؟

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

بالنسبة لعمليات البروكسي، عادةً ما تعطي توقيتات طبقة التطبيق والنجاح المتكرر إشارة أفضل من عرض النطاق الترددي الخام.

تفسير نتائج اختبار سرعة البروكسي المحمول

يمكن أن يخسر البروكسي المحمول كل مقارنة سرعة خام ولا يزال ينجح في المهمة.

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

اقرأ النتائج المحمولة كنطاقات تشغيل

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

استخدم عمليات تشغيل متكررة وابحث عن نطاق قابل للاستخدام، وليس نتيجة مثالية واحدة.

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

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

بالنسبة للبروكسيات المحمولة، يعتبر التباين مهمًا بقدر السرعة. يمكن أن يكسر مسار يتأرجح بين المقبول وغير القابل للاستخدام إجراءات الحساب بطرق تخفيها النتيجة المتوسطة.

يغير التدوير كيفية تقييم البروكسي

يؤثر التدوير على أكثر من تجديد IP. إنه يغير ما يعنيه نتيجة التوقيت.

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

استخدم هذه الجدول كقراءة عملية:

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

المنافذ المشتركة مقابل المنافذ الشخصية

لا ينبغي الحكم على المنافذ المشتركة والشخصية المحمولة بنفس المعيار.

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

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

يوفر أحد المزودين في هذه الفئة، Evoproxy، منافذ موبايل شخصية ومشتركة مع سلوك دوران قابل للتكوين لحالات استخدام IP موبايل فرنسية. هذا الانقسام مفيد أثناء الاختبار لأنه يسمح لك بقياس تكلفة الاتساق مباشرة بدلاً من التخمين.

غالبًا ما ينتج عن منفذ شخصي أبطأ إكمال إجراءات أفضل من منفذ مشترك أسرع. في الإنتاج، معدل الإكمال هو الذي يدفع الفاتورة.

ربط بيانات السرعة بنجاح الإجراءات

تعتبر الكمون الخام، وسرعة التنزيل، والـ ping مقاييس داعمة. مقياس القرار هو ما إذا كان الوكيل ينهي العمل.

بالنسبة لوكلاء الموبايل، قم بمطابقة بيانات التوقيت مع بيانات النتائج من المهمة المستهدفة:

• معدل إكمال تسجيل الدخول
• تكرار نقاط التفتيش أو التحديات
• معدل النجاح عبر تسلسل إجراء قصير
• استمرار الجلسة بعد الدوران
• عدد المحاولات اللازمة لإنهاء المهمة

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

اقرأ اختبارات وكيل الموبايل بنفس الطريقة التي تقرأ بها أنظمة الإنتاج. فضل المسار الذي يكمل سير العمل باستمرار، ويستمر في سلوك الدوران الطبيعي، ويفشل بطرق يمكن التنبؤ بها يمكنك التعامل معها.

كيفية أتمتة مراقبة أداء وكيلك

يساعد اختبار سرعة الوكيل لمرة واحدة في الاختيار. تساعد المراقبة في العمليات.

تريد وظيفة بسيطة تقرأ قائمة الوكلاء، وتصل إلى هدف يتناسب مع عبء العمل الحقيقي الخاص بك، وتكتب النتائج إلى ملف CSV يمكنك فحصه لاحقًا. اجعلها مملة. تبقى السكربتات المملة.

قالب Bash عملي

استخدم ملفًا من الوكلاء بتنسيق قياسي يمكن لفريقك الحفاظ عليه. ثم قم بالتكرار من خلالهم وسجل التوقيت بالإضافة إلى الحالة.

#!/usr/bin/env bash

TARGET_URL="https://TARGET_URL"
PROXY_LIST="proxies.txt"
OUTPUT_FILE="proxy_results.csv"
TIMEOUT=15

if [ ! -f "$OUTPUT_FILE" ]; then
  echo "timestamp,proxy,http_code,time_connect,time_starttransfer,time_total,size_download,speed_download" > "$OUTPUT_FILE"
fi

while IFS= read -r PROXY; do
  [ -z "$PROXY" ] && continue

  TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  RESULT=$(curl -x "$PROXY" \
    -s -o /dev/null \
    --connect-timeout "$TIMEOUT" \
    -w "%{http_code},%{time_connect},%{time_starttransfer},%{time_total},%{size_download},%{speed_download}" \
    "$TARGET_URL")

  echo "$TIMESTAMP,$PROXY,$RESULT" >> "$OUTPUT_FILE"
done < "$PROXY_LIST"

بعض الملاحظات العملية:

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

أضف منطق دفعة خفيف الوزن

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

تشمل الإضافات المفيدة:

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

راقب ما تختبره تطبيقك فعليًا

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

تجيب إعدادات المراقبة القوية على أسئلة بسيطة بسرعة:

• أي الوكلاء أصبحوا أبطأ؟
• أي منهم بدأ يفشل؟
• أي عناوين URL المستهدفة تكشف المشكلة أولاً؟
• هل المشكلة مرتبطة بنوع واحد من الوكلاء أو وجهة واحدة؟

تلك الإجابات تهم أكثر من رقم عرض النطاق الترددي المعزول.

المزالق الشائعة وكيفية تجنبها

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

الأخطاء التي تشوه النتائج

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

معيار أفضل للاحتفاظ به

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

تعتبر النقطة الأخيرة الأكثر أهمية بالنسبة لوكلاء الموبايل. إذا كان المسار مخصصًا للمنصات الاجتماعية، يجب أن يجيب اختبار سرعة الوكيل المفيد على أكثر من "مدى السرعة". يجب أن يجيب على "مدى الاستخدام."

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

إذا كنت بحاجة إلى IP موبايل فرنسي لتقييم سلوك المنصة الحقيقي، فإن Evoproxy يستحق النظر للفرق التي ترغب في اختبار المنافذ المشتركة مقابل الشخصية، وفترات الدوران، واتساق المسارات المحمولة في إعداد عملي بدلاً من فاحص عام.