اختبار بروكسي عبر وجهات مستقلة: كيف تفصل جودة المسار عن أعطال المواقع؟

المشكلة التي تخفيها صفحة فحص واحدة

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

صياغة فرضية قابلة للاختبار

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

اختيار ثلاث وجهات لا تعتمد على جهة واحدة

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

مجموعة التحكم هي مفتاح التفسير

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

قياس مراحل الاتصال بدل الزمن الإجمالي

قس زمن فتح اتصال مع البروكسي، ثم زمن إنشاء نفق CONNECT إن استُخدم، ثم مصافحة TLS مع الوجهة، ووصول أول بايت، واكتمال المحتوى. بعض الأدوات لا تفصل كل مرحلة؛ اذكر بوضوح ما تقيسه وما لا تقيسه. فرّق بين مهلة الاتصال بالبروكسي ومهلة استجابة الخادم النهائي. خطأ HTTP 407 يعني أن البروكسي يطلب مصادقة، كما يوضح RFC 9110؛ ولا يعني وحده أن الموقع حظر عنوان الخروج. كذلك قد يصدر 403 من الوجهة أو من خدمة حماية أمامها، ولا يكشف السبب الكامل.

متى تكون الاستجابة ناجحة فعلًا؟

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

الاختبار المتوازن أفضل من الاختبار المتسلسل

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

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

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

تفسير نتائج متعارضة بين الوجهات

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

التخزين المؤقت يعقّد القياس

قد يعيد المتصفح استخدام اتصال قديم أو نتيجة DNS أو محتوى مخزن، فتبدو محاولة أسرع من الأخرى بلا تحسن حقيقي في البروكسي. خصص قياسًا لاتصال بارد وآخر لاتصال دافئ إذا كانت أداة الاختبار تدعم ذلك، وسجّل سياسة Cache وإعادة استخدام HTTP/2 أو HTTP/3. استخدم بروفايل اختبار لا يحمل بيانات مستخدم حقيقية. لا تحذف جلسات العمل لمجرد تصفير القياس. عندما لا تستطيع التحكم في التخزين المؤقت، اعترف بأن النتيجة تصف تجربة المستخدم في تلك البيئة ولا تعزل زمن الشبكة وحده.

لا تخلط عنوان الخروج بمسار DNS

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

جدول قرار للفريق

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

خطوات عملية قابلة للتكرار

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

المراجع وحدود الدليل

لفهم دلالات CONNECT والمصادقة و HTTP 407 راجع المواصفة https://www.rfc-editor.org/rfc/rfc9110.html . ولمقدمة عن البروكسي والأنفاق راجع https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling . ولأهمية فصل بيئات الاختبار راجع https://playwright.dev/docs/browser-contexts . وعلى إيجي تاج يمكنك استكمال القراءة في دليل فحص DNS و Exit IP: https://egytag.com/ar/articles/فحص-dns-leak-وexit-ip-عند-استخدام-بروكسي-في-المتصفح-topic-20261016-05 . المصادر تشرح المفاهيم والبروتوكولات ولا تشهد على أداء مزود بعينه؛ كل نتيجة أداء تحتاج قياسًا جديدًا موثقًا.

ماذا يجب أن يتضمن التقرير النهائي؟

أدرج وقت الاختبار والمنطقة ونوع البروكسي ومعرّف الجلسة والوجهة وحالة HTTP ومرحلة الفشل وزمن أول بايت والحجم المستلم والتحقق من المحتوى. اذكر حجم العينة والمئينات والمهلة، وأرفق مقارنة بالاتصال المباشر والقيود المعروفة. افصل الاستنتاج التشغيلي عن الأدلة: «نجح في 34 من 36 محاولة» وصف قابل للتحقق، أما «مناسب لكل المواقع» فادعاء لا تثبته تلك العينة. حدّد موعد إعادة القياس عند تغيير الشبكة أو المزود أو سياسة التدوير، حتى لا تتحول نتيجة قديمة إلى حقيقة دائمة.