أفضل Proxy ليس صاحب أقل رقم latency في محاولة واحدة. في تشغيل الحسابات والأتمتة، البروكسي الذي ينجح 99.5% بزمن ثابت قد يكون أفضل من آخر يحقق 40ms أحيانًا ويفشل كثيرًا. Proxy Checker احترافي يجب أن ينتج Profile جودة: الاتصال، التوزيع الزمني، الأخطاء، عنوان الخروج، DNS، الموقع، وسلوك الجلسة عبر عدة محاولات.
ابدأ ب ـSuccess rate وتصنيف الأخطاء
نفذ عشرات الطلبات وسجل connection timeout و TLS error و proxy auth و HTTP response بصورة منفصلة. لا تحذف المحاولات الفاشلة من المتوسط. نسبة النجاح أول مؤشر لأن كل failure قد يسبب retry في الأتمتة ويضاعف الوقت.
استخدم Median و P95 بدل أفضل زمن
سجل latency لكل طلب. Median يصف التجربة المعتادة، و P95 يوضح الذيل البطيء الذي يسبب timeouts للمستخدم. يمكن أيضًا فصل DNS/connect/TLS/TTFB إذا كانت الأدوات تسمح. قارن المزودين بنفس الوجهات ونفس الوقت قدر الإمكان.
خطوات عملية
- ثبت timeout.
- نفذ 50 طلبًا أو أكثر.
- احسب success rate.
- احسب median/P95.
- كرر batch في وقت مختلف.
تحقق من هوية الشبكة
بعد كل session أو عينة، سجل public IP و ASN و Geo و ISP classification. للمزود rotating، قس diversity بدل الاكتفاء بأن IP تغير مرة. للمزود sticky، قس مدة بقاء نفس العنوان. لا تعتبر Geo المدينة حقيقة مطلقة؛ قارن قواعد عند أهمية الموقع.
قائمة مراجعة
- ASN ضمن المتوقع.
- البلد صحيح.
- rotation/sticky policy تتحقق عمليًا.
- IPv4/IPv6 معروفان.
- ال ـIP ليس ضمن denylist داخلية لوجهتك إن كان ذلك مشروعًا ومسموحًا.
اختبر DNS و WebRTC داخل المتصفح
Checker network-level لا يعرف بالضرورة ما يفعله Chromium. بعد نجاح endpoint، افتحه في Profile فعلي وافحص DNS/WebRTC. تأكد أن bypass rules أو DoH لا تصنع مسارًا موازيًا غير مقصود. إذا كان البروكسي مخصصًا ل ـAPI client فقط، وثق أن هذا الاختبار غير مطلوب بدل خلط السيناريوهين.
أضف Soak test وتكلفة
للحسابات طويلة العمر، شغل probe دوريًا لمدة ساعة أو أكثر وسجل الانقطاع وتغير IP. ثم احسب التكلفة لكل GB أو session أو Port مع معدل النجاح. هذه النتيجة تساعدك على معرفة cost per successful request أو cost per stable profile بدل السعر الاسمي.
قائمة مراجعة
- Soak test منفذ.
- معدل الانقطاع معروف.
- التكلفة مرتبطة بالاستخدام.
- النتائج تحفظ تاريخيًا.
- إعادة الاختبار بعد تغيير مزود أو endpoint متاحة.
قِس Jitter والتذبذب بين الطلبات
بروكسي بمتوسط 200ms قد يكون ممتازًا إذا ظلت الطلبات بين 180 و 230ms، وقد يكون مزعجًا إذا تراوحت بين 50ms و 3 ثوانٍ. احسب dispersion أو على الأقل الفرق بين median و P95، وسجل سلاسل التأخير الطويلة. ال ـjitter مهم في صفحات تعتمد على عدة طلبات متتابعة لأن طلبًا واحدًا شديد البطء يمكن أن يؤخر Workflow كاملًا أو يدفعه إلى timeout رغم أن المتوسط العام يبدو جيدًا.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…