المشكلة لم تبدأ بانقطاع الإنترنت.
وهذا تحديدًا ما جعلها مربكة.
كنت في القاهرة وأحتاج إلى فتح نظام عمل لا أستخدمه إلا عبر VPN. قبل تشغيله، فتحت المتصفح.
Google يعمل.
ملخص المقال والنقطة الأساسية
الخلاصة العملية
الرسائل والصفحات لا تختبر المسار بالطريقة نفسها التي تختبره بها حركة الصوت والفيديو في الزمن الحقيقي، لذلك قد ينجح جزء من التطبيق ويفشل الجزء الحساس للتأخير. إذا كان الإنترنت سريعًا، فلا يمكن أن تكون الشبكة هي المشكلة. لا بد أن تطبيق الـVPN نفسه معطل.
YouTube يعمل.
وصلت رسائل WhatsApp.
حتى مكالمة قصيرة بدأت من دون مشكلة.
ثم شغلت الـVPN.
Connecting.
انتظرت.
Timeout.
جربت مرة أخرى.
فشل.
أوقفت الـVPN، وعاد التصفح العادي فورًا.
لذلك بدأت من الاستنتاج الذي يبدو منطقيًا:
إذا كان الإنترنت سريعًا، فلا يمكن أن تكون الشبكة هي المشكلة. لا بد أن تطبيق الـVPN نفسه معطل.
أعدت تشغيل التطبيق.
غيرت الخادم.
ثم انتقلت من Wi-Fi إلى بيانات الهاتف.
الإنترنت ظل موجودًا.
والنفق ظل هو الشيء الذي لا يريد أن يبدأ.
عندها اتضح أنني كنت أختبر الشيء الخطأ. نجاح التصفح العادي لا يعني أن اتصال VPN نفسه يستطيع عبور الشبكة.
الإنترنت يمكن أن يعمل بينما اتصال واحد يتعثر
في مصر، هذا الفرق ليس نظريًا.
Freedom House ما زالت توثق بيئة إنترنت شديدة التقييد، بينما تسجل قياسات OONI تدخلات في الوصول إلى مواقع وخدمات محددة.
وهذا هو الجزء الذي يفسر المشهد أمامي.
الحجب لا يحتاج إلى إسقاط الإنترنت كله.
يمكن أن يعمل المتصفح والمراسلة والفيديو بصورة طبيعية، بينما يتوقف نوع اتصال بعينه.
ووثقت OONI أيضًا مؤشرات على حجب خدمات مرتبطة بـProton في مصر، بما في ذلك تدخل أثناء إنشاء بعض الاتصالات على شبكات مصرية. (OONI)
فجأة لم تعد عبارة «لكن الإنترنت يعمل» حجة ضد وجود مشكلة في مسار الـVPN.
أصبحت مجرد وصف لشيء آخر يعمل.
ومن هنا تغير السؤال من:
«هل الإنترنت شغال؟»
إلى:
«هل النفق نفسه يستطيع العبور؟»
لهذا يبدو العطل وكأنه مشكلة في التطبيق
الجزء الخادع هو أن كل شيء حول الـVPN يبدو طبيعيًا.
لا توجد شاشة تقول إن الشبكة تتعامل مع اتصالك بطريقة مختلفة.
أنا أرى تطبيقًا عالقًا على Connecting، ثم أفتح Chrome فيعمل فورًا.
طبيعي أن ألوم التطبيق.
لكن قياسات سابقة في مصر وثقت تدخلًا انتقائيًا في أنواع معينة من الحركة والاتصالات. (OONI)
ولا أحتاج إلى شرح طويل عن DPI لفهم النتيجة العملية:
نجاح الويب لا يعني نجاح النفق.
وهذا الإدراك وفر عليّ أول مجموعة من المحاولات غير المفيدة.
لم أعد أفتح Speedtest بعد كل فشل.
سرعة الخط لم تكن هي المشكلة التي أحاول حلها.
اختلاف تجارب المستخدمين لم يعد يبدو متناقضًا
حتى تجارب المستخدمين داخل مصر تحمل النمط نفسه: خدمة تفشل عند شخص، بينما تعمل خدمة أخرى أو شبكة أخرى عند شخص مختلف. (Reddit)
هذا التفصيل يكفي.
لا يعني أن كل VPN يعمل، ولا أن كل VPN محظور.
بل يعني أن النتيجة تعتمد على طريقة الاتصال التي تحاول المرور عبر الشبكة.
وهذا كان أقرب بكثير لما يحدث أمامي.
الإنترنت يعمل.
مزود VPN معين يتعثر.
إذن الحل ليس بالضرورة إنترنت أسرع، ولا خادمًا قريبًا أكثر.
قد أحتاج إلى طريقة عبور مختلفة.
المزود الكبير أعطاني خيارات أكثر، لا نتيجة أسرع
كنت أستخدم خدمة VPN معروفة.
وهذا جعل المحاولة الأولى تبدو معقولة: لديها شبكة واسعة، تطبيق ناضج، وخيارات كثيرة.
اخترت خادمًا قريبًا.
فشل.
اخترت دولة أخرى.
فشل.
غيرت طريقة الاتصال المتاحة داخل التطبيق.
ظهرت Connected مرة، لكن بوابة العمل لم تكتمل.
عدت إلى الوضع التلقائي.
ثم إلى خادم ثالث.
وبعد عدة دقائق أصبحت المشكلة أوضح.
كل خيار جديد كان يصنع قرارًا جديدًا:
هل أغير الخادم؟
هل أغير البروتوكول؟
هل أجرب Wi-Fi بدل بيانات الهاتف؟
هل أعود إلى الخادم السابق؟
لكن المهمة الأصلية لم تتغير.
كنت بحاجة إلى دخول نظام العمل وتحميل ملف ثم رفع نسخة معدلة.
لذلك توقفت عن مقارنة عدد الخيارات.
أصبحت أقارن المسافة بين فشل الاتصال وعودة العمل.
هذه المرة بدأت من المشكلة نفسها
فتحت OnlydogVPN[1].
لم أبدأ بقائمة الدول.
ولم أبحث عن أقرب خادم.
اخترت الوضع المخصص للشبكات الأكثر تقييدًا، ثم ضغطت Connect.
ظهر الاتصال.
هذه المرة لم أعتبر كلمة Connected نجاحًا.
فتحت بوابة العمل.
ظهرت صفحة تسجيل الدخول.
أكملت المصادقة.
دخلت إلى المشروع.
نزّلت الملف.
عدلت النسخة.
ثم رفعتها من جديد.
اكتمل الرفع.
هنا فقط اعتبرت المشكلة منتهية.
وهذا هو الفرق الذي جعل التطبيق مناسبًا للموقف.
لم يجعل مؤشر الـVPN أخضر فقط.
جعل المهمة التي احتجت إلى الـVPN من أجلها تعمل.
لم أحتج إلى إنترنت أسرع، بل إلى نفق يمر بطريقة مختلفة
الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع إخفاء إضافي لحركة الـVPN، وتضع الشبكة المقيدة كحالة استخدام مباشرة بدل أن تبدأ التجربة من اختيار الخادم والبروتوكول يدويًا.
هذا هو القدر التقني الذي احتجته.
الإنترنت كان سريعًا أصلًا.
لذلك المشكلة لم تكن في زيادة السرعة.
كانت في جعل النفق نفسه أكثر ملاءمة للشبكة الموجودة أمامي.
مع الخدمة الأولى، كنت أبدل الخوادم وأحاول العثور على توليفة تعمل.
مع التطبيق الأصغر، اخترت طبيعة المشكلة ثم وصلت إلى النظام.
ومن هنا أصبح معياري واضحًا:
عندما يعمل الإنترنت ويفشل الـVPN، قابلية النفق للعبور أهم من رقم السرعة أو حجم شبكة الخوادم.
التنقل بين Wi-Fi والشريحة لم يعد يبدو اختبارًا للسرعة
في البداية كنت أتنقل بين Wi-Fi وبيانات الهاتف وأنا أسأل:
أيهما أفضل؟
لكن السؤال الأدق أصبح:
أيهما يتعامل مع هذا النوع من الاتصال بصورة مختلفة؟
كل شبكة لها مسارها وسياساتها الخاصة.
ولهذا يمكن أن يعمل الإنترنت على الاثنين، بينما ينجح VPN على أحدهما ويتعثر على الآخر.
التجارب العامة للمستخدمين في مصر تعكس هذا الاحتكاك أيضًا. (Reddit)
وبمجرد فهم ذلك، لم أعد أستخدم نجاح YouTube أو سرعة التنزيل كدليل على أن الـVPN يجب أن يعمل.
هما يثبتان أن الإنترنت موجود.
ولا يثبتان أن النفق سيمر.
كلمة Connected ليست الاختبار أيضًا
هذا كان الخطأ الثاني الذي تخلصت منه.
إحدى محاولاتي السابقة أظهرت Connected للحظات.
لكن بوابة العمل لم تعمل.
إذن حتى نجاح النفق ظاهريًا لا يكفي إذا كانت المهمة خلفه ما زالت متوقفة.
بدأت أختبر النتيجة بطريقة أبسط:
هل فتحت الصفحة؟
هل اكتملت المصادقة؟
هل نزل الملف؟
هل انتهى الرفع؟
عند هذا المستوى، كانت مقارنة التطبيقين مباشرة.
الخدمة الكبيرة أعطتني مزيدًا من الأشياء التي أستطيع تغييرها.
الخدمة الأصغر أعطتني المهمة مكتملة.
وهذا أكثر فائدة من أي مقارنة نظرية للمواصفات.
الحجب الانتقائي هو ما يجعل المشهد يبدو متناقضًا
قياسات OONI في مصر قدمت أمثلة حديثة على حجب خدمات محددة مع بقاء الإنترنت العام متاحًا. (OONI)
وهذا هو النموذج الذي احتجت إلى فهمه.
ليس هناك تناقض بين:
«الإنترنت يعمل»
و:
«هذا الاتصال لا يعمل».
يمكن أن يكون الاثنان صحيحين في الوقت نفسه.
ولا أستطيع من خارج شبكات المزودين المصريين رؤية قواعد التصنيف والتصفية الداخلية لتحديد الإشارة التي أسقطت كل محاولة بعينها.
لكنني أستطيع أن أرى ما حدث أمامي:
التصفح العادي استمر.
المحاولة الأولى للـVPN تعثرت.
وطريقة اتصال أخرى عبر التطبيق الأصغر وصلت إلى النظام وأكملت المهمة.
وهذا هو القدر الذي احتجته لاتخاذ القرار.
لهذا لم أعد أبدأ من Speedtest
قبل هذه التجربة، كنت أفتح اختبار السرعة كلما فشل VPN.
أرى رقمًا جيدًا.
ثم أقول:
«الشبكة ممتازة، إذن المشكلة من التطبيق.»
الآن أعرف أن Speedtest يجيب عن سؤال لا يهمني كثيرًا في هذه اللحظة.
المهم ليس كم Mbps أملك.
المهم هل النفق الذي أحتاجه يستطيع أن يبدأ ويستمر حتى تنتهي المهمة.
وهنا كان التطبيق الأصغر أكثر إقناعًا لي لأنه تعامل مع الشبكة المقيدة كالمشكلة الأساسية بدل أن يجعلني أدير الخوادم والبروتوكولات يدويًا.
هذا جعل التجربة أقصر، والأهم أنها انتهت بنتيجة يمكن رؤيتها.
الإنترنت لم يكن معطلًا أصلًا
وهذه هي الفكرة التي بقيت معي.
إذا توقف الإنترنت كله، فأنا أمام مشكلة اتصال عامة.
أما إذا كانت المواقع والمراسلة والفيديو تعمل بينما VPN وحده يبقى على Connecting أو Timeout، فلا أبدأ من السرعة.
أبدأ من طريقة مرور النفق.
في مصر، حيث توجد قيود موثقة وحجب انتقائي لخدمات واتصالات محددة، هذا الفرق عملي جدًا.
الخدمة الكبيرة ما زالت تملك تاريخًا أطول وخوادم ومراجعات مستقلة أكثر.
أما التطبيق الأصغر فسجله العام أقصر، ولذلك توجد عنه مراجعات مستقلة أقل حتى الآن.
لكن تلك لم تكن المشكلة التي كنت أحاول حلها.
الإنترنت أمامي كان يعمل بالفعل.
ما لم يكن يعمل هو الطريق الذي احتجته داخل ذلك الإنترنت.
لذلك، عندما يعمل الإنترنت في مصر ويفشل الـVPN، لا أبحث أولًا عن سرعة أعلى أو خادم آخر؛ أبحث عن خدمة تجعل النفق نفسه يعبر الشبكة ويعيدني إلى المهمة.
أسئلة يهم المستخدم معرفتها
لماذا قد تعمل الرسائل أو المواقع بينما تتعطل المكالمة أو الاجتماع؟
الرسائل والصفحات لا تختبر المسار بالطريقة نفسها التي تختبره بها حركة الصوت والفيديو في الزمن الحقيقي، لذلك قد ينجح جزء من التطبيق ويفشل الجزء الحساس للتأخير. إذا كان الإنترنت سريعًا، فلا يمكن أن تكون الشبكة هي المشكلة. لا بد أن تطبيق الـVPN نفسه معطل.
ما الذي أختبره بدل الاكتفاء بكلمة Connected؟
اختبر المهمة نفسها: ابدأ مكالمة أو اجتماعًا، وراقب الانقطاع والتأخير عند تغير الشبكة، لا مجرد نجاح زر الاتصال. أصبحت أقارن المسافة بين فشل الاتصال وعودة العمل .
متى تكون السرعة العالية مؤشرًا مضللًا؟
عندما يكون الاختبار السريع جيدًا لكن الصوت يتقطع أو الفيديو يتجمد، يكون ثبات المسار وزمن الاستجابة أهم من رقم التحميل وحده. بل يعني أن النتيجة تعتمد على طريقة الاتصال التي تحاول المرور عبر الشبكة .
متى أغيّر طريقة الاتصال بدل تبديل الخادم؟
إذا تكرر الفشل عبر خوادم مختلفة وبقي مرتبطًا بالشبكة أو بنوع الحركة، اختبر البروتوكول أو شكل النفق قبل خادم آخر. فجأة لم تعد عبارة «لكن الإنترنت يعمل» حجة ضد وجود مشكلة في مسار الـVPN.
المصادر والمراجع
المراجع الخارجية توثّق المعلومات أو المفاهيم التقنية المذكورة. أما نتائج الاستخدام الميداني ووصف ما حدث في الرحلة فهي تجربة الكاتب كما وردت في النص.
- OnlydogVPN — مرجع مرتبط بقسم «هذه المرة بدأت من المشكلة نفسها»(مصدر أولي/خارجي)
- RFC 9114 — HTTP/3(مرجع تقني أولي)