دليل VPN على STC السعودية: عندما يبقى الـWi-Fi قوياً لكن المسار نفسه يتغير

أكثر ما أربكني أن أيقونة الـWi-Fi لم تتحرك. كنت أعمل من شقة على راوتر STC Baity 5G، والإشارة داخل الغرفة كاملة. فتحت VPN كبيراً، دخلت إلى لوحة العمل، وبدأ تنزيل ملف. بعد دقائق توقفت الصفحة عن الاستجابة. نظرت إلى الهاتف: ما زلت على الـWi-Fi نفسه. فصلت الـVPN وأعدت الاتصال، فعاد الموقع. بعد فترة حدث الشيء نفسه. أول ما اتهمته كان خادم الـVPN؛ غيرته، ثم غيرت الدولة، ثم أجريت Speedtest وكانت النتيجة جيدة. عندها بدأت أشك في أنني أقيس المشكلة من المكان الخطأ.

كنت أبحث في البداية عن:

أسرع VPN على STC.

لكن تكرار المشكلة جعل السؤال مختلفاً:

ماذا يفعل الـVPN عندما يهتز الطريق خلف الراوتر من دون أن أغير أنا أي شيء؟

هذا هو الفرق الذي لم يظهر في Speedtest، وبدأ يظهر بوضوح أثناء العمل الفعلي.

الـWi-Fi قد يبقى ثابتاً بينما يتغير ما وراءه

تقدم STC باقات Baity 5G كإنترنت منزلي لاسلكي عبر راوتر 5G، كما يمكن لبعض خدماتها الاعتماد على 4G عندما لا تكون 5G متاحة. (STC)

بالنسبة إلى اللابتوب، لا يتغير شيء ظاهر.

نفس الراوتر.

نفس اسم الـWi-Fi.

نفس الأشرطة الممتلئة.

لكن ذلك لا يعني أن الطريق الخارجي ظل في الحالة نفسها طوال الجلسة.

وهنا وجدت تفسيراً أكثر فائدة من فكرة «الخادم بطيء».

إذا اهتز المسار خلف الراوتر، فإن الـVPN الجيد بالنسبة لي ليس فقط الذي يبدأ بسرعة، بل الذي يستطيع استعادة الجلسة من دون أن يجعلني أبدأها يدوياً من جديد.

لهذا لم يعد Speedtest أول حكم عندي

البنية المتنقلة في السعودية سريعة أصلاً؛ تقرير إنترنت السعودية 2025 أظهر مؤشرات قوية للسرعة واستهلاكاً مرتفعاً جداً للبيانات المتنقلة. (CST)

لذلك يمكنني بسهولة أن أرى نتيجة سرعة ممتازة بعد توقف صفحة العمل.

وهذا ما كان يخدعني.

Speedtest يخبرني أن الإنترنت سريع في تلك اللحظة.

لكنه لا يخبرني لماذا توقفت جلسة الـVPN قبل دقيقة، ولا لماذا عادت فور أن ضغطت Disconnect ثم Connect.

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

أصبحت أراقب شيئاً أبسط:

هل الاتصال يتعافى وحده عندما يتغير الطريق؟

أول VPN كان سريعاً… عندما كان كل شيء مستقراً

الخدمة الكبيرة التي بدأت بها لم تكن بطيئة.

عندما اتصلت بخادم جيد، كان التصفح سريعاً والتنزيل ممتازاً.

وهذا جعلني أعتقد أن المشكلة انتهت.

ثم توقف الملف في منتصفه.

فتحت تطبيق الـVPN.

كان لا يزال يعرض Connected.

حاولت فتح صفحة أخرى.

ظلت تدور.

فصلت الاتصال وأعدته.

عادت الصفحة.

بعدها غيرت الخادم، ثم جربت خادماً آخر.

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

وهنا تغير معياري.

لم أعد أبحث عن VPN يحقق أفضل رقم بعد اتصال نظيف.

كنت أبحث عن VPN لا يجعلني أنا آلية التعافي.

تجربة المستخدم أكدت أنني لا يجب أن ألوم الخادم فوراً

هناك تجربة سعودية مختصرة لمستخدم STC 5G لاحظ عدم استقرار أثناء تشغيل VPN، ثم وجد أن جزءاً من المشكلة يظهر حتى من دونه. (Reddit)

وهذا كان كافياً لتثبيت الفكرة عندي.

ليس كل توقف أثناء استخدام VPN دليلاً على أن خادم الـVPN نفسه هو السبب.

الراوتر أو التغطية أو تغير الطريق قد يدخل في الصورة.

لكن هذا لا يعفي الـVPN من الاختبار.

بل يجعل الاختبار أكثر واقعية:

ماذا يفعل عندما يحدث الاضطراب؟

وهنا انتقلت من قياس السرعة إلى قياس الاستمرارية.

هذه المرة لم أبحث عن خادم أسرع

فتحت OnlydogVPN^[1].

بدلاً من اختيار دولة ثم مقارنة Ping، استخدمت الوضع الموجه للشبكة المتغيرة.

اتصل.

فتحت لوحة العمل.

بدأت تنزيل الملف نفسه.

ثم تركت الجلسة تعمل.

بعد فترة حدث تردد قصير في الشبكة.

توقفت الصفحة للحظة.

هذه المرة لم أفتح تطبيق الـVPN.

لم أغير الخادم.

ولم أضغط Disconnect.

انتظرت.

عاد التحميل.

ثم اكتمل الملف.

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

السؤال لم يعد:

هل أحصل على 180 أم 220 Mbps؟

بل:

عندما يهتز الطريق، هل أكمل عملي أم أعود إلى إعدادات الـVPN؟

وفي الاختبار، أكملت عملي.

HTTP/3 كان مفيداً لأنني لم أحتج إلى التفكير فيه

الخدمة تعتمد نقلاً مبنياً على HTTP/3 ومصممة للتعافي على الشبكات الضعيفة أو المتغيرة. HTTP/3 مبني على QUIC، الذي صُمم للتعامل مع تغير مسار الاتصال بصورة أفضل من ربط الجلسة بالطريق الأول فقط. (IETF)

لكنني لم أحتج إلى معرفة التفاصيل أثناء الاستخدام.

الشيء الذي رأيته كان أبسط:

الطريق اهتز.

الاتصال استعاد نفسه.

والملف استمر.

وهذا هو النوع من التقنية الذي أريده في الخلفية.

إذا كنت سأضطر إلى تغيير الخادم أو إعادة النفق يدوياً كلما تغيرت ظروف 5G، فوجود عشرات الخيارات لا يوفر لي الوقت.

المشكلة الشائعة الأولى: اعتبار Wi-Fi القوي شبكة ثابتة

إذا كانت أشرطة Wi-Fi كاملة، من الطبيعي أن تقول:

«الاتصال مستقر».

لكن هذه الأشرطة تصف علاقتي بالراوتر أكثر مما تصف كل ما يحدث بعده.

ومع Baity 5G، الراوتر نفسه يعتمد على اتصال خلوي خلف الـWi-Fi. (STC)

لهذا أصبحت أفصل بين سؤالين:

هل اللابتوب متصل جيداً بالراوتر؟

و

هل طريق الراوتر إلى الإنترنت ظل مستقراً بما يكفي لجلسة VPN طويلة؟

الأول قد يبقى ممتازاً بينما الثاني يتغير.

وهذا بالضبط النوع من الظروف الذي يجعل التعافي التلقائي أهم عندي من سرعة البداية.

المشكلة الثانية: تغيير الخادم بعد كل توقف

هذه كانت عادتي الأسوأ.

الصفحة تتوقف.

أفتح التطبيق.

أغير الخادم.

تعود الصفحة.

فأقرر أن الخادم الجديد «أفضل».

لكن ما فعلته فعلياً في كثير من المرات هو إجبار اتصال الـVPN على البدء من جديد.

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

بعد التجربة مع التطبيق الأصغر، أصبحت أفضل حلاً مختلفاً:

بدلاً من أن أعالج كل اضطراب بخادم جديد، أترك الخدمة تتعافى داخل الاتصال نفسه.

وهذا وفر عليّ الجزء الذي كان يتكرر أكثر من أي شيء آخر.

المشكلة الثالثة: قياس السرعة بعد إصلاح المشكلة يدوياً

كنت أكرر النمط نفسه:

يتوقف الـVPN.

أعيد الاتصال.

أجري Speedtest.

أحصل على نتيجة ممتازة.

ثم أقول:

«الغريب أن VPN سريع لكنه غير مستقر».

الآن لا أرى أي تناقض.

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

لذلك اختباري الحالي مختلف.

أبدأ تنزيلاً أو جلسة عمل.

أتركها مفتوحة.

وأراقب ماذا يحدث عند تذبذب الشبكة.

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

وهذا تحديداً ما يجعل STC 5G حالة مختلفة

مع إنترنت منزلي يعمل عبر 5G، قد أنقل الراوتر، تتغير التغطية أو تتبدل ظروف الاتصال، بينما تظل أجهزتي كلها على Wi-Fi نفسه. (STC)

من وجهة نظري كمستخدم، يبدو كأن شيئاً لم يتغير.

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

أريد أن يفترض أن الطريق قد يهتز، ثم يستعيد نفسه.

وهذا ما جعل التطبيق الأصغر أكثر ملاءمة لاستخدامي على STC من مزود أعطاني خيارات أكثر لكنه أعادني إلى زر Connect كلما ساءت الجلسة.

هناك شيء واحد لا أستطيع رؤيته

لا أستطيع رؤية قرارات الراديو أو التوجيه الداخلية في شبكة STC، لذلك لا أستطيع تحديد اللحظة الدقيقة التي تغير فيها الطريق أو السبب الداخلي لكل توقف.

لكنني أستطيع مقارنة النتيجة على جهازي.

مع الخدمة الكبيرة، كنت أعود إلى Disconnect وConnect وأحياناً أغير الخادم.

مع التطبيق الأصغر، اهتز الطريق ثم عاد التنزيل واكتمل من دون أن أبدأ الجلسة من جديد.

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

الخدمة الكبيرة لديها خوادم أكثر، لكن هذا لم يعد معياري

المزود الكبير لديه شبكة أوسع، تاريخ عام أطول ومراجعات مستقلة أكثر.

أما التطبيق الأصغر فلديه مواقع أقل.

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

لكن STC 5G لم تجعلني أبحث عن دولة إضافية.

جعلتني أبحث عن شيء أكثر عملية:

هل يظل الـVPN مفيداً عندما يتغير الطريق بينما أنا ما زلت جالساً على الـWi-Fi نفسه؟

المزود الكبير كان سريعاً عند بداية الاتصال.

أما التطبيق الأصغر فكان أكثر إقناعاً بعد أن بدأت الشبكة تتغير.

ولهذا أصبحت أقيّم VPN على STC بطريقة مختلفة:

لا أختار أسرع نتيجة Speedtest بعد الضغط على Connect؛ أختار الاتصال الذي يستطيع أن يمر بتغيرات الطريق خلف راوتر 5G ويعيدني إلى الصفحة من دون أن يجعلني أنا زر إعادة التشغيل.