كيف تقيس سرعة البروكسي ووقت تشغيله بنفسك: طريقة قابلة للتكرار

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

الأرقام الأربعة

المقياس	ماذا يجيب عنه	كيف تحصل عليه	القيمة الجيدة النموذجية
زمن الاستجابة (TTFB)	كم ينتظر كل طلب قبل أن تبدأ البيانات في الوصول	`curl -w %{time_starttransfer}` على مورد صغير	مراكز البيانات: +10–50 مللي ثانية فوق الاتصال المباشر؛ السكني/الجوال: +80–300 مللي ثانية
الإنتاجية	مدى سرعة نقل البيانات الضخمة	توقيت تنزيل بحجم ثابت (1–10 ميجابايت)	مراكز البيانات: قريبة من سرعة الخط؛ السكني: 5–50 ميجابت/ثانية؛ الجوال: 5–30 ميجابت/ثانية
معدل النجاح	كم مرة يكتمل الطلب برمز 2xx حقيقي	عد النتائج عبر العديد من الطلبات	>98% على أهداف محايدة؛ أقل على الأهداف المحمية هو خطأ الهدف
وقت التشغيل	كم مرة يكون البروكسي قابلاً للوصول على الإطلاق	فحص اتصال دوري على مدى أيام	>99.5% لمراكز البيانات/مزودي الخدمة؛ المجمعات الدوارة تخفي انقطاعات فردية

التقارير التي تعطي رقم "سرعة" واحدًا عادةً ما تبلغ عن الإنتاجية على تنزيل كبير من بروكسي مركز بيانات في ساعة هادئة — وهو المزيج الأكثر إرضاءً الممكن.

مبادئ قبل الأوامر

قم بقياس الفرق، وليس القيمة المطلقة. قم دائمًا بتشغيل نفس الطلب مباشرة وعبر البروكسي، واحدًا تلو الآخر، وأبلغ عن الفرق. وإلا فإن تباين اتصالك الخاص يختلط مع تباين البروكسي.
نفس الهدف دائمًا. استخدم نقطة نهاية صغيرة وسريعة ومستقرة لا تفرض حدودًا للمعدل — ملف ثابت على شبكة توصيل محتوى كبيرة، أو خادمك الخاص. لا تقم أبدًا بقياس الأداء ضد الموقع الذي تنوي تجريفه؛ استجابة مكافحة الروبوت الخاصة به هي قياس مختلف.
عينات كثيرة موزعة على الوقت. على الأقل 20 طلبًا لكل تشغيلة؛ وتشغيلات في عدة ساعات من اليوم وعلى مدى أسبوع. البروكسيات هي بنية تحتية مشتركة والحمل يتبع ساعات العمل في مناطق المزود وعناوين IP للخروج.
أبلغ عن النسب المئوية، وليس المتوسطات. مهلة زمنية واحدة مدتها 30 ثانية تدمر المتوسط. الوسيط (p50) يخبرك بالتجربة النموذجية؛ p95 يخبرك بتجربة اليوم السيئ؛ كلاهما أهم من المتوسط.
قم بالإحماء. تجاهل الطلب الأول من كل تشغيلة — فإعداد DNS وجلسة TLS يجعله أبطأ من الباقي.
غيّر شيئًا واحدًا في كل مرة. مقارنة بروكسي مركز بيانات من مزود A مع بروكسي سكني من مزود B تقارن الأنواع، وليس المزودين.

زمن الاستجابة باستخدام curl

# مباشر
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# عبر البروكسي
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

عبر البروكسي، time_connect هو الوقت للوصول إلى البروكسي؛ اتصال الوجهة وTLS يحدثان داخل النفق ويظهران في time_appconnect/time_starttransfer. الرقم الذي يجب مقارنته هو ttfb: البروكسي مطروحًا منه المباشر هو زمن الاستجابة الإضافي للبروكسي. قم بتكراره:

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

الإنتاجية

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

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

معدل النجاح

ينتهي كل طلب بواحد من: 2xx مع جسم بالحجم المتوقع؛ 4xx/5xx من الهدف؛ خطأ بروكسي (407، رفض الاتصال، مهلة زمنية)؛ أو صفحة تحدي (CAPTCHA/صفحة وسيطة) مع رمز 200 — الأخير هو ما تفوته العدادات الساذجة، لذا تحقق من الجسم، وليس فقط الرمز. في بايثون:

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

افصل فشل البروكسي (407، أخطاء الاتصال، مهلات زمنية للبروكسي) عن فشل الهدف (403، 429، التحديات). الأول هو مشكلة المزود؛ والثاني يتعلق بسمعة عنوان IP على ذلك الهدف وينتمي إلى اختبار مختلف — انظر كيف تقوم أنظمة مكافحة الروبوت بتقييم الطلبات.

وقت التشغيل

وقت التشغيل هو معدل النجاح عبر الوقت التقويمي. قم بجدولة فحص خفيف — أمر زمن الاستجابة أعلاه، أو CONNECT بسيط — كل 5–15 دقيقة لمدة أسبوع على الأقل، وسجل النتيجة مع طابع زمني، واحسب نسبة الفحوصات الناجحة. هناك دقتان:

المجمعات الدوارة تخفي الانقطاعات. إذا مات أحد مخارج الخروج، تحصل على آخر؛ البوابة نفسها هي التي لديها وقت تشغيل. افحص البوابة، وبشكل منفصل تتبع عدد المرات التي يتغير فيها عنوان IP المعين عندما طلبت جلسة لاصقة — التغيير غير المتوقع هو انقطاع ناعم.
عناوين IP الثابتة (مراكز البيانات، مزودو الخدمة) هي ما يُدعى عادةً بـ "99.9%". 99.9% تعني 43 دقيقة من التوقف شهريًا؛ 99.5% تعني 3.6 ساعات. كلاهما سهل التمييز من أسبوع من فحوصات كل 15 دقيقة.

جدولة التشغيلات

جدول بسيط لكنه ذو معنى: زمن الاستجابة + النجاح (20–50 طلبًا) في الساعات 03:00، 09:00، 14:00 و20:00 بالتوقيت المحلي لعناوين IP للخروج، كل يوم لمدة سبعة أيام؛ الإنتاجية مرة واحدة لكل تشغيلة؛ فحص اتصال كل 15 دقيقة طوال الوقت. هذا بضع مئات من الكيلوبايتات يوميًا لكل بروكسي لزمن الاستجابة وعشرات الميجابايتات للإنتاجية — ميسور التكلفة حتى على الخطط لكل جيجابايت إذا استخدمت ملفًا صغيرًا. قم بتشغيله من جهاز يظل قيد التشغيل (VPS صغير مثالي) مع cron، واكتب سطر CSV واحد لكل طلب. تصنيفاتنا المنشورة — على سبيل المثال تصنيف السرعة وتصنيف الموثوقية — مبنية بالضبط على هذا النوع من السلاسل على مدى أسبوع، وليس من بعد ظهر واحد.

قراءة النتائج

زمن استجابة p50 قريب من معيار النوع وp95 ضمن ~3× p50: صحي. p95 أكبر بعدة مرات من p50 يعني ازدحامًا متقطعًا — المزود مفرط في الاشتراك في أوقات الذروة.
معدل نجاح أقل من ~97% على هدف محايد من أخطاء جانب البروكسي: مشكلة بنية تحتية، وليست مشكلتك.
النهار أسوأ بكثير من الليل: سعة مشتركة؛ اسأل عن خيارات مخصصة أو اقبلها في الجدولة.
أرقام رائعة على مركز البيانات، ضعيفة على السكني من نفس المزود: طبيعي — منتجات مختلفة؛ قارن السكني بالسكني.
وقت تشغيل أقل من الادعاء: لديك الآن سجل لتظهره للدعم، وهو worth أكثر من شكوى.

أخيرًا، ضع النوع في الاعتبار. البروكسيات السكنية والجوالة أبطأ بطبيعتها — فحركة المرور تعبر فعليًا خط منزل أو برج خلوي — وشراؤها من أجل السرعة هو خطأ في التصنيف؛ انظر مقارنة أنواع البروكسيات. قم بقياسها مقابل فئتها الخاصة وما تتطلبه مهمتك فعليًا. لاحظ أيضًا أن الاتصال عبر البروكسي يعمل عبر HTTP/2، وليس HTTP/3، لذا قارن المثل بالمثل عندما يكون خط الأساس المباشر على موقع يدعم QUIC (التفاصيل).

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

كيف أختبر سرعة البروكسي؟

اطلب نفس المورد الصغير مباشرة وعبر البروكسي، عدة مرات، في عدة أوقات من اليوم؛ قارن الوقت حتى أول بايت (زمن الاستجابة) وبشكل منفصل قم بتوقيت تنزيل بحجم ثابت (الإنتاجية). أبلغ عن الوسيط والنسب المئوية 95، وليس المتوسطات.

ما هو زمن الاستجابة الجيد للبروكسي؟

نسبة إلى اتصال مباشر: بروكسيات مراكز البيانات تضيف عشرات المللي ثانية؛ السكنية والجوالة تضيف حوالي 80–300 مللي ثانية لأن حركة المرور تمر عبر اتصال استهلاكي. احكم على كل نوع وفقًا لمعياره الخاص.

كيف أتحقق من وقت تشغيل البروكسي؟

افحصه وفقًا لجدول (كل 5–15 دقيقة) لمدة أسبوع على الأقل، وسجل كل نتيجة، واحسب نسبة الفحوصات الناجحة. للمجمعات الدوارة افحص البوابة؛ لعناوين IP الثابتة افحص عنوان IP نفسه.

لماذا تختلف نتائجي عن ادعاءات المزود؟

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

هل يجب أن أقيس الأداء ضد الموقع الذي أريد تجريفه؟

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

كم عدد العينات التي أحتاجها؟

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