كيف تفرّق بين حجب عنوان IP وحجب بروتوكول VPN؟ اختباران يوقفان تبديل الخوادم عشوائيًا

الخادم الأول لم يتصل.

انتقلت إلى الثاني.

فشل أيضًا.

الثالث ظل على Connecting قليلًا ثم أعادني إلى نقطة البداية.

عندها فعلت الشيء الذي يجعل تشخيص المشكلة أصعب: غيّرت كل شيء في وقت واحد. دولة أخرى، خادم آخر، Wi-Fi بدل بيانات الهاتف، ثم بروتوكول مختلف.

وبعد عدة محاولات اتصل الـVPN أخيرًا.

المشكلة أنني لم أعرف لماذا.

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

هنا تغير هدفي. لم أعد أريد العثور على خادم يعمل بالمصادفة. أردت أن أعرف ما الشيء الذي يجب تغييره عندما يفشل الاتصال.

المشكلة ليست دائمًا في الخادم

صار هذا السؤال أكثر إلحاحًا في إيران خلال 2026.

في يناير، شهدت البلاد انقطاعًا واسعًا للإنترنت الدولي، وسجل Proton VPN في 7 يناير ارتفاعًا في التسجيلات من إيران تجاوز 1000% فوق المستوى المعتاد. وبعد نحو 88 يومًا، عاد الوصول إلى الإنترنت الدولي في مايو. (Reuters^[1]) (Proton VPN^[2])

لكن عودة الإنترنت لا تعني أن جميع طرق الوصول أصبحت متساوية.

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

من شاشة الهاتف، تبدو كل هذه الحالات متشابهة: زر Connect لا يصل إلى شيء.

وهنا بالضبط كان عليّ أن أتوقف عن معاملتها كعطل واحد.

الاختبار الأول: غيّر الخادم فقط

رجعت إلى البداية، لكنني هذه المرة أبقيت طريقة الاتصال كما هي.

الخادم الأول فشل.

انتقلت إلى الثاني.

ثم الثالث.

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

الفكرة أبسط مما تبدو: حجب عنوان IP يستهدف الوجهة، بينما حجب البروتوكول يستهدف طريقة الاتصال نفسها. (IRTF / RFC 9505^[3])

ومن هنا جاءت قاعدتي الأولى:

إذا غيّرت الخادم فقط وبدأ الاتصال يعمل، فابدأ بالاشتباه في عنوان الخادم.

وهنا تكون شبكة الخوادم الكبيرة مفيدة فعلًا. عنوان لا يصل؟ لديك بدائل.

لكن هذا لم يكن ما حدث معي.

الرابع فشل مثل الأول.

والخامس أيضًا.

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

وهذا جعل الخطوة التالية أكثر وضوحًا.

إذا استمر الفشل، غيّر طريقة الاتصال

توقفت عن التنقل بين الدول وغيّرت طريقة الاتصال بدلًا من ذلك.

هذه المرة تغير السلوك.

وهنا يصبح الاحتمال الثاني أقوى: المشكلة ليست عنوان خادم واحد، بل شكل حركة الـVPN وهي تعبر الشبكة.

أنظمة التصفية تستطيع التعرف على بعض بروتوكولات وأشكال حركة أدوات التجاوز، لذلك قد تغيّر عنوان IP مرارًا بينما يظل الاتصال يظهر بالطريقة نفسها. (IRTF / RFC 9505^[3])

ومن هنا جاءت القاعدة الثانية:

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

هذا الاختبار وحده اختصر عليّ الكثير من الوقت.

بدل تغيير الخادم والدولة والبروتوكول معًا، أصبحت أغير متغيرًا واحدًا وأراقب النتيجة.

وتظهر الفكرة نفسها عمليًا في نقاشات المستخدمين؛ ففي تجربة منشورة لمستخدم إيراني، نجح OpenVPN عبر TCP على Linux بينما احتاج Android إلى خيار اتصال مختلف. (Reddit^[4]) هذا يكفي لتوضيح النقطة: عبارة «الـVPN لا يعمل» لا تخبرنا وحدها أين المشكلة.

بعدها بدأت أنظر إلى الخدمة الكبيرة التي كنت أستخدمها بطريقة مختلفة.

كنت أملك خوادم كثيرة، لكنني أكرر الاتصال نفسه

الخدمة الأولى لديها شبكة واسعة، وهذه ميزة حقيقية.

لكن واجهتها جعلت رد فعلي الطبيعي هو فتح قائمة الخوادم:

أي دولة؟

أي مدينة؟

أي خادم؟

في البداية كان ذلك منطقيًا. وبعد فشل عدة عناوين بالطريقة نفسها، لم يعد كذلك.

إذا كان عنوان IP هو المشكلة، فأنا أريد عناوين بديلة.

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

هذه كانت النقطة التي قلبت المقارنة بالنسبة لي.

لم أعد أسأل: كم خادمًا يمكنني تجربته؟

بدأت أسأل: هل يمكنني تغيير شكل الاتصال نفسه بدل الاستمرار في تغيير وجهته؟

ومن هنا أصبح منطقيًا أن أجرب تطبيقًا يبدأ من حالة الشبكة، لا من الخريطة.

هذه المرة لم أبدأ بدولة

فتحت OnlydogVPN^[5].

اخترت الإعداد المخصص للشبكة المقيدة، ثم شغلت الاتصال.

وبدل البقاء داخل تطبيق الـVPN ومراقبة الأرقام، عدت مباشرة إلى الخدمة التي كنت أحاول استخدامها.

فتحت الصفحة.

أرسلت الرسالة التي كانت معلقة.

ثم بدأ الاتصال الذي كنت أحتاجه.

وهذه النتيجة كانت أهم من أي اختبار سرعة.

بعدها فقط أصبح تفسير الفرق مفيدًا.

الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع تمويه إضافي لحركة الاتصال. أي أنها لا تكتفي بإعطائي عنوان خادم مختلف، بل تغيّر أيضًا طريقة ظهور الاتصال للشبكة عندما تكون قابلية تمييز حركة الـVPN هي المشكلة.

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

وهنا تحولت كلمة «تمويه» بالنسبة لي من مصطلح تقني في صفحة المواصفات إلى ميزة مرتبطة مباشرة بما كنت أعانيه.

متى يصبح «خادم آخر» هو الاختيار الخطأ؟

كنت أتعامل سابقًا مع تغيير الخادم كحل تلقائي لأي فشل.

الآن أستخدمه كاختبار.

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

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

عندها أحتاج إلى تغيير نوع المحاولة.

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

شبكة مقيدة.

تشغيل الاتصال.

ثم العودة إلى المهمة الأصلية.

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

الفرق ليس في اسم البروتوكول، بل في النتيجة

بعد هذه التجربة توقفت عن حفظ أسماء البروتوكولات كما لو كانت درجات في ترتيب ثابت.

المهم ليس أن OpenVPN «أفضل» أو WireGuard «أفضل» أو أن أي تقنية أخرى تحمل اسمًا أحدث.

المهم هو ما إذا كانت طريقة الاتصال مناسبة للشبكة التي أمامك.

إذا كان تغيير الخادم يحل المشكلة، فالمشكلة غالبًا في الوجهة.

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

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

وبعد أن نجح الاتصال، ظهر الاحتكاك التالي

بعد دقائق احتجت إلى استخدام الخدمة نفسها من جهاز ثانٍ.

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

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

بعد قليل كان الاتصال يعمل على الجهازين.

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

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

متى تظل الخدمة الأكبر أفضل؟

الخدمة الأصغر لديها مواقع خوادم أقل، وتاريخها العام أقصر، وعدد المراجعات والاختبارات المستقلة المتراكمة عنها أقل مما لدى الشركات الكبرى.

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

لكن هذا لم يكن ما حدث أمامي.

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

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

إذا غيّر الخادم النتيجة، ففكّر في الـIP؛ وإذا تغيرت الخوادم وبقي الفشل حتى تغيرت طريقة الاتصال، فقد حان الوقت للتوقف عن مطاردة العناوين.