لماذا لا يحل تغيير DNS حجب التطبيقات دائمًا؟ لأن المشكلة قد تبدأ بعد العثور على العنوان

كان الحل يبدو أسهل من المشكلة.

Discord لا يفتح، وأول نصيحة وجدتها كانت: غيّر DNS.

وضعت 1.1.1.1 على الهاتف. أغلقت التطبيق وفتحته.

Connecting.

جربت 8.8.8.8.

النتيجة نفسها.

أعدت تشغيل Wi-Fi، ثم الهاتف، ودخلت إلى إعدادات الراوتر لأتأكد أن DNS الجديد محفوظ فعلًا.

Google يفتح. YouTube يعمل. بقية التطبيقات طبيعية.

Discord وحده لم يتغير.

هنا بدأت أشك في الفكرة نفسها. ربما لم أختر DNS سيئًا؛ ربما كنت أصلح جزءًا لم يكن معطلًا أصلًا.

وهذا هو الفرق الذي كان سيوفر عليّ معظم المحاولات: تغيير DNS يفيد عندما تكون المشكلة في DNS، لكنه لا يغير ما يحدث للاتصال بعد العثور على العنوان.

لماذا ينجح تغيير DNS أحيانًا؟

شهرة هذه النصيحة لها سبب منطقي.

DNS يحول اسم الموقع أو الخدمة إلى عنوان يستطيع الهاتف الوصول إليه. فإذا تدخلت الشبكة في هذه الخطوة وأعادت إجابة خاطئة، يمكن لمحلل DNS آخر أن يحل المشكلة مباشرة. وتضع OONI التلاعب بـDNS ضمن أساليب الحجب المعروفة. (OONI^[1])

لكن معرفة العنوان ليست سوى البداية.

بعدها لا يزال الهاتف بحاجة إلى الوصول إلى الخادم وإنشاء الاتصال بالخدمة. وهذا هو الجزء الذي جعل اضطراب Discord في مصر خلال يناير 2026 مثالًا مفيدًا: في 11 و12 يناير، وثقت المنصة بالتعاون مع Masaar تعطل Discord على شبكتي WE وVodafone، وأظهرت القياسات أن الفشل ظهر لاحقًا أثناء إنشاء الاتصال المشفر المرتبط بالخدمة. (Discord^[2])

أي أن الهاتف كان يعرف أين يذهب.

المشكلة كانت في الطريق بعد ذلك.

وفجأة أصبحت نتيجة تجربتي واضحة: DNS الجديد يعمل، لكن Discord لا يصل.

كنت أغيّر دفتر العناوين، لا الطريق

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

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

أما إذا ظل التطبيق على Connecting بعد تطبيق DNS جديد، فإن التنقل بين 1.1.1.1 و8.8.8.8 و9.9.9.9 لا يغير الجزء الذي يفشل.

وهكذا صار لدي اختبار بسيط:

أغير DNS مرة.

أتأكد أن الإعداد طُبق.

أعود إلى التطبيق.

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

ومن هنا أصبحت نصيحة أخرى كنت أراها أثناء مشكلة Discord أكثر منطقية: استخدم WARP.

لماذا يعمل WARP عندما لا يفعل تغيير DNS شيئًا؟

في نقاشات المستخدمين المصريين أثناء اضطراب Discord، تكرر اقتراح 1.1.1.1 وWARP كحل سريع. (Reddit^[3]) والالتباس بينهما سهل جدًا.

لكن الفرق جوهري.

وضع 1.1.1.1 الخاص بـDNS يغير محلل أسماء النطاقات. أما WARP فيمرر حركة الجهاز نفسها عبر نفق Cloudflare. (Cloudflare^[4])

وهذا يفسر مشهدًا يتكرر كثيرًا:

شخص يقول: «غيرت DNS ولم يعمل».

وشخص آخر يقول: «1.1.1.1 اشتغل معي».

قد يكون الثاني قد شغّل WARP، وبالتالي لم يغير DNS فقط؛ لقد غيّر مسار حركة التطبيق.

وهنا تغير تفسير النتيجة بالنسبة لي.

إذا لم يؤثر DNS اليدوي في Discord، ثم بدأ التطبيق بالعمل عندما مرت الحركة عبر نفق آخر، فلا أحتاج إلى «DNS أفضل».

أحتاج إلى طريق مختلف.

وعند هذه النقطة انتهت مرحلة البحث عن رقم DNS جديد.

عندما غيرت الطريق، عاد التطبيق

كان Discord ما يزال على Connecting.

فتحت OnlydogVPN^[5].

لم أبدأ باختيار دولة أو خادم يدويًا. اخترت الإعداد المناسب لشبكة مقيدة، شغلت الاتصال، ثم عدت مباشرة إلى Discord.

اختفت Connecting.

ظهرت القنوات.

وصلت الرسائل.

ثم دخلت الاتصال الصوتي الذي كنت أحاول فتحه منذ البداية.

هذه النتيجة جعلت الفرق بين الحلين ملموسًا.

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

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

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

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

لم يعد: أي DNS أجرب الآن؟

أصبح: هل المشكلة أصلًا عند DNS؟

متى أتوقف عن تغيير DNS؟

منذ تلك التجربة أصبحت أتعامل مع DNS كخطوة أولى سريعة، لا كحل عام لكل حجب.

إذا غيرته وعاد التطبيق إلى العمل، ممتاز. انتهت المشكلة بأبسط طريقة.

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

أنتقل إلى شيء يغير حركة التطبيق نفسها.

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

لا أحتاج إلى حفظ أسماء طبقات الشبكة كي أستفيد من ذلك.

يكفي أن أراقب النتيجة.

DNS جديد، والسلوك نفسه؟ أنتقل إلى الخطوة التالية.

هذا وحده جعل التشخيص أقصر بكثير.

الواجهة الأبسط منعتني من حل المشكلة الخطأ

في بداية القصة لم أكن أريد تعلم شيء عن DNS أصلًا.

كنت أريد فتح Discord.

لكن خلال دقائق وجدت نفسي أعدل إعدادات الهاتف، ثم الراوتر، وأقرأ عن WARP، وأقارن عناوين DNS.

المشكلة التقنية بدأت تبتلع المهمة الأصلية.

ولهذا كان البدء من حالة «شبكة مقيدة» مفيدًا أكثر مما توقعت.

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

التسلسل أصبح أقصر:

الخدمة لا تعمل.

DNS لم يحلها.

أشغل الاتصال المناسب للشبكة المقيدة.

أعود إلى الخدمة.

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

«غيّر DNS» و«شغّل VPN» ليستا النصيحة نفسها

خلال اضطراب Discord في مصر، ارتفعت تسجيلات Proton VPN الجديدة بنحو 320% فوق المستوى المعتاد. (Proton VPN^[6]) عدد كبير من المستخدمين كان يبحث في الوقت نفسه عن طريق يعيد الخدمة بسرعة.

ولهذا انتشرت النصائح المختصرة:

غيّر DNS.

جرّب WARP.

شغّل VPN.

لكنها لا تفعل الشيء نفسه.

DNS يساعد الهاتف على العثور على الوجهة بطريقة مختلفة.

WARP ينقل حركة الجهاز عبر مسار آخر.

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

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

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

ليست المشكلة أن DNS حل ضعيف

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

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

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

كنت أريد إخراج Discord من شاشة Connecting بعد أن فشل تغيير DNS.

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

إذا غيّرت DNS وبقي التطبيق عالقًا في النقطة نفسها، فلا تبحث عن رقم DNS رابع؛ غيّر الطريق الذي تسلكه حركة التطبيق.