في الصباح، كان الـVPN يعمل.
وهذا بالضبط ما جعل المشكلة بعد الظهر أكثر إزعاجًا.
كنت في موسكو أعمل من مقهى. اتصلت بالخادم الذي استخدمته في اليوم السابق، ثم فتحت أدوات العمل.
كل شيء طبيعي.
خلاصة المقال والسياق
ما الخلاصة العملية من هذه التجربة؟
إذا كان الإنترنت العادي يعمل لكن تطبيق الـVPN لا يصل إلى Connected، ثم تتغير النتيجة عند تغيير الشبكة مع بقاء الجهاز والخادم نفسيهما، فالمسار إلى النفق يصبح الاحتمال الأقوى.
نقاط سريعة قبل متابعة القصة
- كيف أعرف أن المشكلة في طريق الـVPN لا في الموقع الذي أريد فتحه؟ إذا كان الإنترنت العادي يعمل لكن تطبيق الـVPN لا يصل إلى Connected، ثم تتغير النتيجة عند تغيير الشبكة مع بقاء الجهاز والخادم نفسيهما، فالمسار إلى النفق يصبح الاحتمال الأقوى.
- لماذا يمكن أن يعمل الإنترنت بينما يفشل VPN؟ لأن الشبكة تستطيع السماح بالتصفح العادي ومعاملة خوادم VPN أو بروتوكولاتها بطريقة مختلفة. نجاح Google أو البريد لا يثبت أن طريق النفق نفسه مفتوح.
مصدر المنتج: الموقع الرسمي لـ OnlydogVPN
بعد نحو ساعة توقفت الصفحة التي كنت أستخدمها.
ظننت أن Wi-Fi انقطع.
فتحت موقعًا محليًا.
يعمل.
نظرت إلى تطبيق الـVPN.
Reconnecting…
انتظرت.
تحولت إلى:
Connecting…
ثم حاول مرة أخرى.
ونفس النتيجة.
كنت قد فعّلت Auto-Reconnect تحديدًا كي لا أتعامل مع هذه اللحظة يدويًا.
لكنني اكتشفت المشكلة في الاسم نفسه:
إعادة الاتصال تلقائيًا لا تفيدني إذا كان التطبيق يعيدني إلى الطريق الذي توقف عن العمل.
الخادم الذي يعمل الآن قد لا يعمل بعد ساعة
أصبح هذا النوع من الفشل أكثر أهمية مع تشديد القيود على VPN في روسيا. خلال 2026 ارتفعت تنزيلات الخدمات بقوة، بينما استمرت حملات الحجب وتغيرت الخوادم والمسارات التي يستطيع المستخدم الاعتماد عليها. (Reuters)
وفي موجة أغسطس، تأثرت عناوين IP وشبكات استضافة، بينما بقيت لدى بعض الخدمات خوادم أخرى قابلة للاستخدام. وفي بعض الحالات كان الانتقال إلى موقع آخر كافيًا لاستعادة الاتصال. (Meduza)
هذه هي النقطة التي تهمني.
إذا كان الخادم A يعمل صباحًا ثم أصبح غير صالح بعد الظهر، فليست مهمتي الحقيقية أن أجعل التطبيق يعيد محاولة A إلى ما لا نهاية.
أحتاجه أن يجد B.
وهنا بدأت أفرق بين ميزتين كنت أعتبرهما شيئًا واحدًا.
Auto-Reconnect ليس هو التعافي
إعادة الاتصال قد تكون بسيطة جدًا:
الخادم يفشل.
التطبيق يحاول الخادم نفسه مرة أخرى.
ثم مرة أخرى.
أما التعافي الذي أحتاجه فهو مختلف:
الطريق الحالي لم يعد مفيدًا، لذلك يجب الانتقال إلى طريق صالح.
الفكرة موجودة تقنيًا منذ زمن. OpenVPN يدعم إعداد أكثر من خادم بحيث يستطيع العميل الانتقال إلى بديل بعد استمرار فشل الوجهة الأولى. (OpenVPN)
لكنني لا أريد أن أبني هذه القائمة بنفسي وأنا في المقهى.
أريد التطبيق أن يحولها إلى سلوك طبيعي.
ومن هنا أصبح سؤالي أقل اهتمامًا بكلمة Reconnect وأكثر اهتمامًا بما يحدث بعدها:
هل تعود الصفحة التي أحتاجها؟
المزود الكبير كان يحاول، وأنا كنت أختار البديل
الخدمة التي بدأت بها ناضجة ولديها شبكة خوادم واسعة.
وهذا مفيد عندما أريد دولة أو موقعًا محددًا.
لكن عندما توقف الخادم الحالي، بقي التطبيق في دورة إعادة الاتصال.
انتظرت.
ثم فتحت قائمة الخوادم بنفسي.
اخترت دولة أخرى.
عاد الإنترنت.
بعد فترة توقف الاتصال مجددًا.
فتحت القائمة مرة أخرى.
اخترت خادمًا ثالثًا.
وهنا أصبح Auto-Reconnect يبدو أقل تلقائية مما توقعت.
التطبيق يتولى الضغط على Connect.
لكنني ما زلت الشخص الذي يراقب الفشل ويقرر متى يتخلى عن الخادم ويبحث عن بديل.
وتظهر المشكلة نفسها في تجارب المستخدمين: خادم كان يعمل يتوقف فجأة، ثم تبدأ رحلة البحث اليدوي عن بديل. (Reddit)
هذا هو الجزء المهم.
المستخدم لا يحتاج إلى زر Connect أذكى.
يحتاج إلى ألا يصبح هو نظام الـfailover.
لذلك غيرت الاختبار
كنت سابقًا أفتح صفحة الخصائص وأسأل:
هل يوجد Auto-Reconnect؟
إذا كانت الإجابة نعم، أعتبر المهمة منتهية.
الآن أختبر شيئًا مختلفًا.
أستخدم الاتصال فترة طويلة.
وعندما يتوقف الطريق، لا ألمس التطبيق مباشرة.
أراقب.
هل يعيد الاتصال؟
والأهم:
هل يعود التطبيق الذي كنت أستخدمه من دون أن أفتح قائمة الخوادم؟
هذا هو الفارق بين محاولة تلقائية وتعافٍ تلقائي.
وعندما أصبح المعيار واضحًا، جربت الخيار الأصغر الذي كان عندي.
هذه المرة لم أبحث عن الخادم البديل
شغلت OnlydogVPN على الوضع الموجه للشبكات المقيدة.
اتصلت.
عدت إلى العمل.
بعد فترة توقف الطريق للحظات.
ظهر الانقطاع في الصفحة.
توقعت السيناريو المعتاد.
افتح تطبيق الـVPN.
اختر بلدًا.
جرب خادمًا.
ارجع إلى الصفحة.
لكنني لم أفعل شيئًا.
انتظرت قليلًا.
عاد الاتصال.
أعدت تحميل الصفحة.
فتحت.
أكملت الرسالة التي كنت أكتبها وأرسلتها.
لم أعرف أي خادم أصبح البديل.
ولم أحتج إلى معرفته.
هذه كانت النتيجة التي كنت أبحث عنها منذ البداية.
ليس:
التطبيق حاول إعادة الاتصال.
بل:
الاتصال عاد من دون أن أتحول أنا إلى قائمة خوادم بشرية.
هنا أصبح التعافي أهم من الخادم نفسه
الخدمة تستخدم نقلًا قائمًا على HTTP/3 مع تمويه إضافي، وهي مصممة للتعامل مع الشبكات المقيدة والطرق التي تتغير أثناء الاستخدام.
بالنسبة لي، القيمة العملية كانت واضحة.
اخترت حالة الشبكة مرة واحدة.
ثم عندما توقف الطريق، تعامل التطبيق مع الاسترداد بدل أن يعيدني إلى خريطة الدول.
لا أستطيع من جهازي رؤية قواعد الفلترة الداخلية أو تحديد ما إذا كان الاسترداد حدث بتغيير خادم أو إعادة بناء المسار أو تعديل آخر داخل الاتصال.
لكنني لا أحتاج إلى رؤية ذلك كي أحكم على النتيجة.
الطريق توقف.
لم أفتح الإعدادات.
ثم عاد الاتصال.
وهذا بالضبط ما كنت أريد من كلمة Automatic أن تعنيه.
كثرة البدائل لا تكفي إذا كان اختيارها يدويًا
وهنا تغيرت أيضًا نظرتي إلى عدد الخوادم.
كنت أفكر:
كلما زاد عدد الخوادم، زادت فرص النجاة من الحجب.
هذا صحيح من جهة توفر البدائل.
لكن البدائل التي لا ينتقل إليها التطبيق إلا بعد أن أكتشف الفشل وأختار واحدًا منها بنفسي لا تحل كامل المشكلة.
في بيئة يمكن أن يتوقف فيها عنوان يعمل قبل ساعة، يصبح السؤال الأهم:
كم خطوة تفصلني عن الطريق التالي؟
ثلاث نقرات؟
تجربة دولة؟
اختيار بروتوكول؟
أم يعود الاتصال بينما أنا ما زلت في الصفحة نفسها؟
في اختباري، هذا هو المكان الذي أصبحت فيه الخدمة الأصغر أكثر راحة من المزود الأكبر.
لم تكن بحاجة إلى أكبر قائمة خوادم أمامي.
كانت بحاجة إلى ألا تجعلني أستخدم تلك القائمة كلما مات المسار الحالي.
ثم تغيرت الشبكة بدل الخادم
في المساء خرجت من المقهى والهاتف ما زال متصلًا.
اختفى Wi-Fi عند الباب.
انتقل الهاتف إلى بيانات الجوال.
توقف الاتصال لحظة.
ثم عاد.
هذه ليست حالة حجب خادم بالمعنى نفسه، لكنها كشفت فائدة ثانية للتصميم نفسه.
من وجهة نظر المستخدم، سبب فقدان الطريق ليس أهم شيء في اللحظة نفسها.
قد يكون الخادم.
قد تكون شبكة الفندق.
قد أتحول من Wi-Fi إلى 5G.
ما يهمني هو ألا تتحول كل واحدة منها إلى جلسة إعادة إعداد.
ولهذا أصبحت أضع الاسترداد في مرتبة أعلى من الاتصال الأول.
الاتصال مرة واحدة سهل.
الاختبار الحقيقي هو ما يفعله التطبيق عندما لا يعود الطريق الأول صالحًا.
الآن أفرق بين ثلاث ميزات تحمل أسماء متشابهة
Auto-Connect يعني أن التطبيق يبدأ الاتصال تلقائيًا.
Auto-Reconnect يعني أنه يحاول إعادة النفق إذا انقطع.
أما الذي أبحث عنه على شبكة تتغير فيها الخوادم الصالحة فهو:
Recovery.
أن يفشل المسار الحالي، ثم أعود إلى اتصال يعمل من دون أن أدير أنا عملية البحث عن البديل.
المزود الأكبر ما زال يمتلك تاريخًا أطول، مواقع أكثر ومراجعات مستقلة أكثر.
والخدمة الأصغر لديها انتشار جغرافي أقل وسجل عام أقصر.
لكن المشكلة التي دفعتني إلى البحث عن هذه الميزة لم تكن قلة الدول.
كان لدي الكثير منها بالفعل.
المشكلة أن الخادم الذي استخدمته قبل ساعة لم يعد مفيدًا، بينما كنت في منتصف العمل.
في هذه اللحظة لا يهمني كثيرًا عدد البدائل الموجودة في القائمة.
يهمني من المسؤول عن الوصول إلى واحد منها.
المزود الأول أعاد محاولة الاتصال، ثم ترك لي اختيار الطريق التالي.
أما الخدمة الأصغر فأعادت لي اتصالًا صالحًا من دون أن أفتح قائمة الخوادم.
ولهذا عندما أبحث عن VPN يعيد الاتصال تلقائيًا بعد حجب الخادم، لا أسأل كم مرة سيضغط Connect من أجلي؛ أسأل هل سيجد طريقًا جديدًا قبل أن أضطر أنا إلى البحث عنه.
أسئلة سريعة بعد التجربة
كيف أعرف أن المشكلة في طريق الـVPN لا في الموقع الذي أريد فتحه؟
إذا كان الإنترنت العادي يعمل لكن تطبيق الـVPN لا يصل إلى Connected، ثم تتغير النتيجة عند تغيير الشبكة مع بقاء الجهاز والخادم نفسيهما، فالمسار إلى النفق يصبح الاحتمال الأقوى.
لماذا يمكن أن يعمل الإنترنت بينما يفشل VPN؟
لأن الشبكة تستطيع السماح بالتصفح العادي ومعاملة خوادم VPN أو بروتوكولاتها بطريقة مختلفة. نجاح Google أو البريد لا يثبت أن طريق النفق نفسه مفتوح.
هل تبديل الخادم عدة مرات هو أول اختبار؟
ليس دائمًا. إذا كانت الخوادم كلها تستخدم نمط اتصال تتعامل معه الشبكة بالطريقة نفسها، فأنت تكرر الاختبار نفسه. تغيير الشبكة أو طريقة النقل يعطي معلومة أوضح.
ما الميزة التي تصبح مهمة في VPN عندما تتغير الشبكات كثيرًا؟
اتصال يستطيع التكيف مع Wi‑Fi وبيانات الهاتف والمسارات المقيدة، مع طريقة بديلة عند فشل النفق العادي. الاعتمادية في الشبكة الفعلية أهم من عدد الخوادم وحده.