في البداية لم أعتقد أن لدي مشكلة مع الـVPN أصلًا.
الهاتف على 5G. الرسائل تصل. الفيديو يبدأ فورًا. وحتى اختبار السرعة أعطاني نتيجة أكثر من كافية لما أريد فعله.
ثم شغلت الـVPN.
خلال ثوانٍ أصبح الهاتف يتصرف كما لو أن الإنترنت انقطع.
ملخص المقال والنقطة الأساسية
الخلاصة العملية
الرسائل والصفحات لا تختبر المسار بالطريقة نفسها التي تختبره بها حركة الصوت والفيديو في الزمن الحقيقي، لذلك قد ينجح جزء من التطبيق ويفشل الجزء الحساس للتأخير. إذا كان اتصال يعمل وآخر يفشل، فالمشكلة ليست أن الكويت ببساطة «أغلقت الـVPN». الأرجح أن طريقة إنشاء النفق نفسه أصبحت جزءًا من المشكلة .
أوقفت النفق، فعادت الصفحات. شغلته مرة أخرى، فتوقفت.
ظننت أن التطبيق يحتاج فقط إلى إعادة تشغيل. بعدها اتهمت الخادم. ثم بدأت أتنقل بين دول مختلفة في القائمة.
لكن النتيجة بقيت نفسها: الإنترنت يعمل قبل الضغط على Connect، ويتوقف بعده.
عندها أصبح السؤال مختلفًا. لم تعد المشكلة «هل الإنترنت في الكويت بطيء؟». كان الإنترنت أمامي سريعًا أصلًا. المشكلة هي لماذا يؤدي تشغيل الـVPN نفسه إلى كسر اتصال كان يعمل قبل ثوانٍ.
وهذا الاختلاف هو الذي قادني لاحقًا إلى الحل.
المشكلة لم تكن انقطاع الإنترنت
الكويت شهدت بالفعل اضطرابات حقيقية في خدمة الإنترنت خلال 2026. ففي 4 مارس أعلنت هيئة الاتصالات معالجة خلل وعودة الخدمة إلى طبيعتها. (وكالة الأنباء الكويتية KUNA)
لكن ما كان أمامي لا يشبه انقطاعًا عامًا.
في الانقطاع الحقيقي تتوقف الخدمة نفسها. هنا كنت أضغط Disconnect فتعود الصفحات فورًا، ثم أضغط Connect فتتعطل مرة أخرى.
هناك أيضًا نظام رسمي في الكويت لحجب وإلغاء حجب محتوى الويب، وتوضح هيئة الاتصالات أنها تتعامل مع طلبات الحجب على مستوى مزودي الخدمة. (CITRA) لذلك ليس غريبًا أن تتعامل الشبكة مع أنواع مختلفة من الحركة بطرق مختلفة.
وبالفعل، ظهرت الصورة نفسها في تجارب مستخدمين داخل الكويت: الإنترنت يعمل، ثم يتعطل التصفح عند تشغيل VPN معين، بينما تستمر خدمات أو شبكات أخرى في العمل بصورة طبيعية. (Reddit) هذه الملاحظة كانت أهم بالنسبة لي من أي نقاش طويل حول ما إذا كان «VPN يعمل في الكويت» بصورة عامة.
لأن السؤال لم يعد عامًا أصلًا.
إذا كان اتصال يعمل وآخر يفشل، فالمشكلة ليست أن الكويت ببساطة «أغلقت الـVPN». الأرجح أن طريقة إنشاء النفق نفسه أصبحت جزءًا من المشكلة.
وهنا أدركت أنني كنت أحاول إصلاح الشيء الخطأ.
كنت أغير الدولة، لا طريقة الاتصال
بدأت بخدمة VPN كبيرة ومعروفة.
كان ذلك منطقيًا. لديها تاريخ طويل، تطبيق ناضج، دعم واسع وقائمة خوادم تجعل من السهل افتراض أن الحل موجود في مكان ما بينها.
فشل الاتصال الأول.
اخترت خادمًا آخر.
ثم دولة أخرى.
ثم عدت إلى منطقة أقرب.
بعض المحاولات ظلت عالقة عند Connecting. بعضها بدا أنه اتصل، لكن الإنترنت توقف بمجرد إنشاء النفق.
بعد عدد كافٍ من المحاولات بدأت قائمة الخوادم الكبيرة تبدو أقل فائدة مما توقعت. لم أكن أحصل على حلول أكثر؛ كنت أحصل على أماكن أكثر لتكرار المشكلة نفسها.
وكان هذا هو التحول الأساسي في اختباري.
إذا كان خادم واحد معطلًا، فمن الطبيعي تجربة خادم ثانٍ. لكن عندما يتكرر النمط عبر وجهات متعددة، يصبح السؤال: هل الوجهة هي المشكلة أصلًا، أم الطريقة التي يحاول بها التطبيق الوصول إليها؟
لا أستطيع رؤية قواعد التصفية وإدارة الحركة داخل شبكات المشغلين في الكويت أو تحديد السبب الداخلي لكل محاولة فاشلة. لكن ما كان ظاهرًا أمامي يكفي لاتخاذ قرار عملي: التصفح العادي يمر، بينما النفق الذي أحاول إنشاءه لا يمر بالطريقة نفسها.
لذلك توقفت عن البحث عن الخادم رقم 15.
بدأت أبحث عن VPN يعالج طريقة عبور الشبكة نفسها.
عندها فقط أصبحت كلمة obfuscation مفيدة
كنت قد رأيت مصطلح obfuscation كثيرًا في تطبيقات VPN، وكنت أتعامل معه كميزة تقنية يمكن تجاهلها.
هذه المرة أصبح له معنى مباشر جدًا.
بعض أنفاق VPN تحمل أنماطًا يمكن تمييزها عن حركة الويب المعتادة. تقنيات الإخفاء تغيّر شكل هذه الحركة بحيث تصبح أقل وضوحًا عند التصنيف على الشبكة.
ولا تحتاج الفكرة إلى شرح أطول من ذلك.
الهدف ليس جعل البروتوكول يبدو أكثر تعقيدًا للمستخدم. الهدف أن تقل احتمالية تعثر النفق بالطريقة نفسها التي تعثر بها الاتصال التقليدي.
لهذا بدأت خدمات معروفة أصلًا في استخدام QUIC كطبقة لإخفاء حركة WireGuard وجعل تمييزها أصعب. (Mullvad)
بالنسبة لي، هذه المعلومة قلبت المقارنة رأسًا على عقب.
وجود 80 دولة مفيد إذا كان الاتصال يعمل.
أما إذا كنت لا أتجاوز شاشة Connecting، فأنا لا أحتاج دولة إضافية. أحتاج طريقة اتصال مختلفة.
وهنا دخل الخيار الثاني إلى القصة.
هذه المرة انتهت شاشة Connecting
فتحت OnlydogVPN[1].
لم أبدأ بخريطة عالم ولا بقائمة بروتوكولات. استخدمت الإعداد المبني على الحالة التي أمامي، ثم بدأت الاتصال.
انتظرت.
هذه المرة اختفت شاشة Connecting.
ظهر أن النفق متصل.
فتحت الصفحة التي كنت أحاول الوصول إليها قبل دقائق.
حملت فورًا.
انتقلت إلى التطبيق التالي. عمل أيضًا. فتحت ملفًا، عدت إلى المتصفح، ثم تركت الهاتف فترة قصيرة وعدت إليه.
الاتصال بقي قائمًا.
بعد دقائق أدركت أنني توقفت عن التفكير في الـVPN بالكامل.
وهذا، في الواقع، كان أفضل اختبار.
لم أكن أريد تطبيقًا يجعلني أقضي المساء في فحص عنوان IP أو مقارنة عشرات المواقع. كنت أريد تشغيل الحماية والعودة إلى الشيء الذي كنت أفعله قبل أن تتحول الشبكة إلى مشكلة.
وقد حدث ذلك.
بعد نجاح المهمة أصبحت طريقة عمل التطبيق منطقية: الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع إخفاء إضافي لحركة الاتصال. بدل الاعتماد فقط على نفق تقليدي ثم الطلب مني تجربة وجهة أخرى عند فشله، صُمم الاتصال نفسه ليكون أكثر ملاءمة للشبكات التي لا تتعامل جيدًا مع حركة VPN الواضحة.
لم أحتج إلى قراءة ذلك قبل الضغط على Connect.
النتيجة سبقت الشرح، وهذا هو الترتيب الذي أفضله.
ثم تغيرت الشبكة تحت الاتصال
بعد فترة خرجت من المكان الذي كنت فيه.
الهاتف كان على Wi-Fi، ثم انتقل إلى 5G.
كنت أتوقع تلك اللحظة القصيرة المزعجة التي تجعلني أفتح تطبيق VPN من جديد وأنتظر إعادة الاتصال.
لكنني أكملت استخدام الهاتف.
الصفحة التالية فتحت، وبقيت الجلسة موجودة.
هنا ظهر سبب ثانٍ جعل HTTP/3 مناسبًا لهذا السيناريو. فهو يعمل فوق QUIC، المصمم للتعامل بصورة أفضل مع تغير مسار الاتصال عندما ينتقل الجهاز بين شبكات مختلفة. (IETF)
عمليًا، هذا يعني شيئًا أبسط بكثير من اسم البروتوكول:
دخلت المكان على Wi-Fi.
خرجت منه على بيانات الهاتف.
ولم أحتج إلى إصلاح النفق مرة ثانية.
هذه لم تكن ميزة منفصلة أبحث عنها عندما بدأت. لكنها أعطتني سببًا للاحتفاظ بالتطبيق بعد أن انتهت المشكلة الأولى.
لأن الـVPN المفيد على الهاتف ليس فقط الذي يتصل في اللحظة الأولى. هو أيضًا الذي لا يجبرني على التفكير فيه كلما تغيرت الشبكة تحته.
وهنا توقفت عن تفسير كل فشل بأنه «حجب VPN»
في البداية كنت مستعدًا للقفز إلى استنتاج كبير: ربما VPN لا يعمل في الكويت الآن.
لكن تجربة المستخدمين نفسها لا تدعم حكمًا بهذه البساطة. في النقاش الكويتي الذي لفت انتباهي، كان مستخدم يعاني المشكلة على أكثر من مزود، بينما كان آخرون يستخدمون شبكات أو خدمات مختلفة من دون المشكلة نفسها، ثم تغير الوضع مرة أخرى لاحقًا. (Reddit)
هذا التفصيل يكفي.
ليس كل فشل VPN انقطاعًا عامًا، وليس كل اتصال ناجح دليلًا على أن كل خدمة ستعمل بالطريقة نفسها.
الأكثر فائدة هو النظر إلى اللحظة التي يحدث عندها الفشل.
إذا كان الإنترنت لا يعمل حتى قبل تشغيل VPN، فابدأ بالشبكة نفسها.
إذا كان الإنترنت طبيعيًا ثم يختفي بمجرد تشغيل VPN، فأنا الآن أنظر إلى طريقة إنشاء النفق أولًا.
وإذا كان تطبيق يتصل بينما آخر يبقى عالقًا، فهذا بالنسبة لي دليل عملي على أن تصميم الاتصال أهم من اسم الدولة الظاهر في القائمة.
هذه الطريقة في التفكير اختصرت عليّ الكثير من التجربة العشوائية.
ما يزال للمزود الكبير شيء لا يملكه الخيار الأصغر
لو كان هدفي مختلفًا، ربما كنت سأختار بشكل مختلف.
المزود الكبير يملك مواقع أكثر، سجلًا عامًا أطول، وعددًا أكبر من المراجعات المستقلة. إذا كنت أحتاج كل أسبوع إلى عنوان IP في مدينة مختلفة أو مجموعة ضخمة من دول الخروج، فهذا تفوق واضح.
الخدمة الأصغر لديها مواقع أقل وتاريخ عام أقصر.
لكن تلك لم تكن المشكلة التي جعلتني أفتح متجر التطبيقات.
كنت أبحث لأن الهاتف لديه إنترنت، بينما تشغيل الـVPN يحوله فجأة إلى جهاز بلا اتصال.
وفي هذه الحالة يصبح ترتيب الأولويات مختلفًا.
مئة خادم إضافي لا يفيدني قبل نجاح النفق الأول.
عشرات أعلام الدول لا تساعدني بينما زر Connect ما زال يدور.
والواجهة الغنية بالإعدادات لا تصبح ميزة عندما أحتاج إلى تخمين أي إعداد منها يستطيع تجاوز المشكلة الحالية.
الخيار الأكبر أعطاني أشياء أكثر لأجرّبها.
الخيار الأصغر أعطاني عددًا أقل من القرارات، ثم أعادني إلى الإنترنت.
وهذا بالضبط ما كنت أحتاجه.
الاختبار الذي أبدأ به الآن
لو حدثت المشكلة مرة أخرى في الكويت، لن أبدأ بـSpeedtest.
ولن أتنقل فورًا بين عشر دول.
سأفتح صفحة من دون VPN. إذا عملت، أشغل النفق وأعيد المحاولة.
ثم أبدل بين Wi-Fi وبيانات الهاتف إن أمكن.
بهذه الطريقة أعرف بسرعة إن كنت أتعامل مع مشكلة إنترنت عامة أم مشكلة تحدث عند إنشاء الـVPN نفسه.
ومن هناك يصبح الاختيار أسهل.
إذا كانت المشكلة عند النفق، أريد خدمة صُممت للتعامل مع هذه اللحظة تحديدًا، لا مجرد خدمة تملك قائمة أطول بعد نجاح الاتصال.
المزود الكبير كان أقوى على الورق، لكنه جعلني أبحث يدويًا عن تركيبة تنجح.
الخيار الأصغر غيّر طريقة عبور الاتصال، أنشأ النفق، وحافظ عليه عندما انتقلت من Wi-Fi إلى 5G.
ولهذا، عندما يعمل الإنترنت في الكويت ثم ينهار بمجرد تشغيل الـVPN، أصبحت الأولوية بالنسبة لي واضحة: طريقة عبور النفق للشبكة أهم من عدد الخوادم التي لن أستفيد منها أصلًا قبل أن ينجح الاتصال.
أسئلة يهم المستخدم معرفتها
لماذا قد تعمل الرسائل أو المواقع بينما تتعطل المكالمة أو الاجتماع؟
الرسائل والصفحات لا تختبر المسار بالطريقة نفسها التي تختبره بها حركة الصوت والفيديو في الزمن الحقيقي، لذلك قد ينجح جزء من التطبيق ويفشل الجزء الحساس للتأخير. إذا كان اتصال يعمل وآخر يفشل، فالمشكلة ليست أن الكويت ببساطة «أغلقت الـVPN». الأرجح أن طريقة إنشاء النفق نفسه أصبحت جزءًا من المشكلة .
ما الذي أختبره بدل الاكتفاء بكلمة Connected؟
اختبر المهمة نفسها: ابدأ مكالمة أو اجتماعًا، وراقب الانقطاع والتأخير عند تغير الشبكة، لا مجرد نجاح زر الاتصال. إذا كان خادم واحد معطلًا، فمن الطبيعي تجربة خادم ثانٍ. لكن عندما يتكرر النمط عبر وجهات متعددة، يصبح السؤال: هل الوجهة هي المشكلة أصلًا، أم الطريقة التي يحاول بها التطبيق الوصول إليها؟
متى تكون السرعة العالية مؤشرًا مضللًا؟
عندما يكون الاختبار السريع جيدًا لكن الصوت يتقطع أو الفيديو يتجمد، يكون ثبات المسار وزمن الاستجابة أهم من رقم التحميل وحده. هناك أيضًا نظام رسمي في الكويت لحجب وإلغاء حجب محتوى الويب، وتوضح هيئة الاتصالات أنها تتعامل مع طلبات الحجب على مستوى مزودي الخدمة. (CITRA) لذلك ليس غريبًا أن تتعامل الشبكة مع أنواع مختلفة من الحركة بطرق…
متى أغيّر طريقة الاتصال بدل تبديل الخادم؟
إذا تكرر الفشل عبر خوادم مختلفة وبقي مرتبطًا بالشبكة أو بنوع الحركة، اختبر البروتوكول أو شكل النفق قبل خادم آخر. الهدف ليس جعل البروتوكول يبدو أكثر تعقيدًا للمستخدم. الهدف أن تقل احتمالية تعثر النفق بالطريقة نفسها التي تعثر بها الاتصال التقليدي.
المصادر والمراجع
المراجع الخارجية توثّق المعلومات أو المفاهيم التقنية المذكورة. أما نتائج الاستخدام الميداني ووصف ما حدث في الرحلة فهي تجربة الكاتب كما وردت في النص.
- OnlydogVPN — مرجع مرتبط بقسم «هذه المرة انتهت شاشة Connecting»(مصدر أولي/خارجي)
- WireGuard — Protocol & Cryptography(مرجع تقني أولي)
- RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport(مرجع تقني أولي)
- RFC 9114 — HTTP/3(مرجع تقني أولي)