تغير الخطأ أمامي، فظننت أنني أصلحت المشكلة. كنت في طهران أحاول فتح خدمة خارجية أحتاجها للعمل بعد عودة جزء كبير من الاتصال الدولي في مايو 2026. في البداية لم يجد المتصفح اسم الموقع أصلًا. غيرت DNS في المتصفح إلى اتصال مشفر، فاختفى الخطأ وبدأ يحاول الوصول إلى الصفحة. للحظة اعتقدت أن الأمر انتهى: المشكلة كانت DNS فقط. لكن الصفحة بقيت معلقة، وتطبيق سطح المكتب الذي أحتاجه لم يتحسن. كنت قد أصلحت مرحلة العثور على العنوان، لا الطريق إلى الخدمة نفسها. هنا تغير سؤالي: إذا كان DNS المشفر يساعد، فهل الأفضل أن يمر DNS داخل نفق VPN يحمي بقية الاتصال أيضًا؟
كنت قد بدأت بمشكلة تبدو صغيرة:
أي DNS أستخدم؟
لكن اختفاء رسالة الخطأ من دون أن تفتح الخدمة كشف المشكلة الأكبر.
ملخص المقال والنقطة الأساسية
الخلاصة العملية
إذا تكرر الفشل مع خوادم مختلفة بينما تتغير النتيجة عند تغيير البروتوكول أو شكل الاتصال، فالمشكلة أقرب إلى طريقة العبور من موقع الخادم. عندما يكون DNS المحلي جزءًا من الحجب، فإن استخدام DNS مشفر يمكن أن يمنع مزود الشبكة من قراءة الاستعلام أو تغييره بالطريقة المعتادة.
ليس المهم فقط من يجيب عن اسم الموقع، بل هل يبقى الطريق صالحًا بعد الحصول على الجواب.
عودة الإنترنت لم تعنِ اختفاء التصفية
في إيران خلال 2026 كان هذا الفرق عمليًا جدًا.
بعد فترة طويلة من القيود والانقطاعات، عاد جزء كبير من الوصول الدولي في أواخر مايو، لكن ذلك لم يعنِ أن الخدمات الخارجية عادت كلها إلى وضع طبيعي. (Reuters[1])
وهذا جعل التجربة مربكة.
الإنترنت يعمل.
بعض المواقع تفتح.
ثم موقع آخر يفشل بطريقة تبدو كأنها مشكلة DNS بسيطة.
وكان هذا احتمالًا حقيقيًا؛ قياسات OONI وثقت استخدام التلاعب بـDNS لحجب مواقع على شبكات إيرانية، بحيث يحصل المستخدم على نتيجة مختلفة بدل عنوان الموقع الحقيقي. (OONI[2])
لذلك كان تغيير DNS أول خطوة معقولة.
وقد نجحت جزئيًا.
وهنا بالضبط كدت أستنتج أكثر مما تسمح به النتيجة.
تغيير DNS أزال الخطأ الأول فقط
فكرة DNS بسيطة في الاستخدام اليومي.
أكتب اسم الموقع.
يحتاج الجهاز إلى معرفة عنوانه.
يسأل DNS.
ثم يبدأ الاتصال.
عندما يكون DNS المحلي جزءًا من الحجب، فإن استخدام DNS مشفر يمكن أن يمنع مزود الشبكة من قراءة الاستعلام أو تغييره بالطريقة المعتادة. (Cloudflare[3])
وهذا ما رأيته.
قبل التغيير:
اسم الموقع لا يُحل.
بعده:
المتصفح يعرف إلى أين يريد الذهاب.
لكن الصفحة ما زالت لا تصل.
كان هذا هو الانتقال المهم في التجربة.
لأنني لم أعد أستطيع القول إن المشكلة «DNS فقط».
لقد تجاوزت الباب الأول واصطدمت بالثاني.
العثور على العنوان لا يعني الوصول إليه
في القياسات الإيرانية نفسها ظهرت إلى جانب التلاعب بـDNS تدخلات في مراحل لاحقة من الاتصال أيضًا. (OONI[2])
وهذا يفسر ما حدث من دون الحاجة إلى تحويل الموضوع إلى درس شبكات.
الشبكة تستطيع تعطيل اسم الموقع.
وإذا تجاوزت ذلك، يمكن أن يبقى الاتصال نفسه عرضة للتعطيل.
لهذا تغير سلوك المتصفح من خطأ DNS واضح إلى انتظار طويل.
الاسم أصبح معروفًا.
لكن الطريق إليه لم يصبح حرًا.
وفي تلك اللحظة لم أعد أبحث عن «DNS أفضل».
بدأت أبحث عن طريقة تجعل DNS والاتصال الذي يأتي بعده جزءًا من المسار نفسه.
تطبيق سطح المكتب جعل ضعف حل المتصفح أوضح
حتى داخل المتصفح، كان DNS المشفر قد حسن خطوة واحدة فقط.
أما تطبيق العمل على سطح المكتب فلم يكن جزءًا من هذا التعديل أصلًا.
وهنا ظهر الاحتكاك الحقيقي.
أنا لا أحتاج الوصول إلى موقع واحد داخل نافذة واحدة.
لدي تطبيق عمل.
وتخزين سحابي.
ومراسلة.
وخدمات تعمل في الخلفية.
إذا كنت سأضبط كل تطبيق على حدة، فقد حولت مشكلة اتصال إلى سلسلة إعدادات منفصلة.
لذلك أصبحت فكرة DNS داخل النفق أكثر من مجرد إعداد خصوصية.
أصبحت طريقة لتجنب إدارة DNS كتجربة مستقلة لكل جزء من الجهاز.
DNS داخل النفق يخرج السؤال من الطريق المحلي
عندما يعمل VPN ويوجه DNS عبر النفق، لا يعتمد الجهاز على resolver المحلي لدى مزود الإنترنت بالطريقة المعتادة. هذا هو أيضًا السبب الذي يجعل خدمات VPN تهتم بمنع تسرب DNS خارج النفق. (Proton VPN[4])
بالنسبة لي، كانت الفائدة واضحة:
بدل أن أسأل DNS المحلي عن اسم الموقع ثم أحاول حماية ما يحدث بعد ذلك، يصبح السؤال نفسه جزءًا من الاتصال المشفر.
وهنا بدت الإجابة سهلة:
نعم، وضع DNS داخل النفق أفضل إذا كانت المشكلة هي التلاعب باستعلامات DNS.
لكنني اصطدمت فورًا بشرط أهم.
يجب أن يكون هناك نفق يعمل أصلًا.
الـVPN الأول لم يصل إلى المرحلة التي تهمني
فتحت خدمة VPN كبيرة كنت أستخدمها من قبل.
لديها تاريخ أطول وخوادم كثيرة، لذلك بدا استخدامها منطقيًا.
اخترت خادمًا.
Connecting.
ثم فشل.
غيرت الدولة.
النتيجة نفسها.
وهنا أصبحت محاولتي السابقة مع DNS مفيدة بطريقة جديدة.
أنا كنت أبحث عن طريقة لوضع DNS داخل VPN.
لكن الخدمة لم تستطع إنشاء النفق على الشبكة أمامي.
إذا كان النفق نفسه لا يمر، فلن أصل أصلًا إلى المرحلة التي يصبح فيها DNS داخله مفيدًا.
وهذا قلب ترتيب الأولويات عندي.
لم يعد:
أي DNS أضع داخل الـVPN؟
أصبح:
أي VPN يستطيع أولًا إنشاء طريق أستطيع أن أضع DNS وحركة التطبيقات داخله؟
تجربة DNS عام آخر لم تعد تبدو تقدمًا
كان يمكنني الاستمرار في تغيير resolvers.
واحد عام.
ثم آخر.
ثم DoH مختلف.
وفي نقاشات مستخدمين داخل إيران تظهر هذه المحاولات فعلًا عندما تصبح بعض خدمات DNS نفسها صعبة الوصول. (Reddit[5])
لكن هذا التفصيل اختصر الفكرة بدل أن يوسعها:
إذا كانت الشبكة تستطيع التدخل في أكثر من مرحلة، فإن تبديل DNS بلا نهاية يعالج جزءًا صغيرًا من المشكلة.
كنت أريد طريقًا واحدًا يحمل:
طلب DNS.
ثم الاتصال بالموقع.
ثم حركة التطبيق بعد فتحه.
ولهذا توقفت عن تعديل المتصفح.
اخترت الشبكة المقيدة بدل اختيار DNS جديد
فتحت OnlydogVPN[6].
الخدمة لديها مواقع خوادم أقل من المزود الأكبر، وهذه هي المقايضة الواضحة إذا كان هدفي اختيار أكبر عدد ممكن من الدول.
لكنني لم أكن أبحث عن علم جديد على الخريطة.
ولا عن resolver جديد.
كنت أريد أن يمر النفق.
اخترت إعداد الشبكة المقيدة.
ضغطت اتصال.
ظهر النفق.
بعدها عدت إلى الخدمة التي بدأت منها.
فتحت.
ثم فتحت تطبيق سطح المكتب.
اتصل هو أيضًا.
وأرسلت الملف الذي كنت أحاول الوصول إليه منذ البداية.
هذه كانت أول مرة في الجلسة لا أتعامل فيها مع DNS باعتباره مشكلة منفصلة تحتاج مني إلى إصلاح يدوي.
أصبح مجرد جزء من اتصال يعمل.
الفرق أن النفق حل المشكلة الأكبر أولًا
الخدمة تستخدم نقلًا مبنيًا على HTTP/3 مع تمويه إضافي للحركة، بحيث يتغير شكل الاتصال على الشبكة المقيدة بدل الاعتماد على نفق تقليدي يتعثر قبل أن يبدأ.
لا أستطيع رؤية قواعد التصفية الداخلية للشبكة أو تحديد القاعدة الدقيقة التي فصلت بين المحاولات.
لكن تسلسل النتائج كان واضحًا:
DNS المشفر داخل المتصفح أصلح العثور على الاسم، لكن المهمة لم تكتمل.
النفق التقليدي لم يتصل.
المسار المموه اتصل، وبعدها عمل الاسم والموقع وتطبيق سطح المكتب.
وهنا أصبحت قيمة DNS داخل النفق أوضح بكثير.
هو مفيد لأن DNS يصبح جزءًا من طريق صالح للاستخدام، لا لأنه وحده يحول الشبكة المقيدة إلى شبكة مفتوحة.
كنت أخلط بين «تغيير DNS» و«إدخاله في النفق»
في البداية بدت الفكرتان متشابهتين.
لكنهما ليستا الشيء نفسه.
عندما أغير DNS في المتصفح، فأنا أصلح طريقة العثور على الاسم لذلك المسار.
أما عندما يعمل VPN ويوجه DNS داخله، فإن استعلام الاسم وحركة التطبيقات يمران ضمن اتصال أوسع لا يعتمد على DNS المحلي بالطريقة نفسها.
وهذا هو الفرق الذي احتجته.
مشكلتي لم تكن:
هل 1.1.1.1 أفضل أم resolver آخر؟
بل:
هل سيظل مزود الإنترنت قادرًا على التدخل بين كتابة الاسم واستخدام الخدمة؟
كنت أريد تقليل هذه المساحة كلها.
لا إصلاح أول خطوة فيها فقط.
لذلك لم يعد DNS هو معيار المقارنة الرئيسي
DNS داخل النفق مهم جدًا عندما يكون الحجب في DNS.
لكنه لا ينفعني قبل وجود النفق.
وهذه كانت النقطة التي غيرت قراري.
الخدمة الأولى كانت تملك خوادم أكثر، لكنها لم تصل على الشبكة أمامي إلى المرحلة التي يصبح فيها DNS داخلها مفيدًا.
الخيار الأصغر بدأ من مشكلة أكثر إلحاحًا: تمرير النفق عبر الشبكة المقيدة.
بعد نجاح ذلك، أصبح DNS جزءًا طبيعيًا من الطريق، وعادت الخدمة التي أحتاجها على المتصفح والتطبيق معًا.
ولهذا لم أعد أتعامل مع السؤال على أنه «هل DNS داخل النفق يمنع الحجب؟» فقط.
السؤال الأصح عندي أصبح:
هل لدي نفق يستطيع أولًا العبور، ثم يأخذ استعلام DNS وبقية الاتصال بعيدًا عن الطريق الذي كان مزود الإنترنت يتحكم فيه؟
وعندما تحقق ذلك، انتهت المهمة التي لم يستطع تغيير DNS وحده إكمالها.
أسئلة يهم المستخدم معرفتها
كيف أعرف أن المشكلة في طريقة عبور الاتصال لا في الخادم نفسه؟
إذا تكرر الفشل مع خوادم مختلفة بينما تتغير النتيجة عند تغيير البروتوكول أو شكل الاتصال، فالمشكلة أقرب إلى طريقة العبور من موقع الخادم. عندما يكون DNS المحلي جزءًا من الحجب، فإن استخدام DNS مشفر يمكن أن يمنع مزود الشبكة من قراءة الاستعلام أو تغييره بالطريقة المعتادة.
لماذا لا يكفي تغيير المنفذ أو DNS في كل حالات الحجب؟
المنفذ وDNS يعالجان طبقات محددة فقط؛ إذا كانت الشبكة تميّز البروتوكول أو تمنع الطريق بعد حل الاسم، فلن يغيرا سبب الفشل. بدأت أبحث عن طريقة تجعل DNS والاتصال الذي يأتي بعده جزءًا من المسار نفسه.
ما أول اختبار يقلل التخمين قبل تبديل عدة خوادم؟
غيّر متغيرًا واحدًا في كل مرة: الشبكة أو البروتوكول أو العميل، ثم أعد نفس المهمة حتى تعرف أي تغيير أثر فعلًا. عندما يعمل VPN ويوجه DNS عبر النفق، لا يعتمد الجهاز على resolver المحلي لدى مزود الإنترنت بالطريقة المعتادة. هذا هو أيضًا السبب الذي يجعل خدمات VPN تهتم بمنع تسرب DNS خارج النفق.
متى أحتاج إلى تغيير البروتوكول أو شكل النفق؟
عندما يفشل الاتصال نفسه قبل أن تصل إلى الموقع أو التطبيق، يصبح تغيير طريقة النفق منطقيًا أكثر من الاستمرار في تبديل الخوادم. إذا كان النفق نفسه لا يمر، فلن أصل أصلًا إلى المرحلة التي يصبح فيها DNS داخله مفيدًا.
المصادر والمراجع
المراجع الخارجية توثّق المعلومات أو المفاهيم التقنية المذكورة. أما نتائج الاستخدام الميداني ووصف ما حدث في الرحلة فهي تجربة الكاتب كما وردت في النص.
- Reuters — مرجع مرتبط بقسم «عودة الإنترنت لم تعنِ اختفاء التصفية»(مصدر أولي/خارجي)
- OONI — مرجع مرتبط بقسم «عودة الإنترنت لم تعنِ اختفاء التصفية»(مصدر أولي/خارجي)
- Cloudflare — مرجع مرتبط بقسم «تغيير DNS أزال الخطأ الأول فقط»(مصدر أولي/خارجي)
- Proton VPN — مرجع مرتبط بقسم «DNS داخل النفق يخرج السؤال من الطريق المحلي»(مصدر أولي/خارجي)
- Reddit — تجربة مستخدم مرتبطة بالنقطة المذكورة في النص(تجربة مستخدم)
- OnlydogVPN — مرجع مرتبط بقسم «اخترت الشبكة المقيدة بدل اختيار DNS جديد»(مصدر أولي/خارجي)
- Cloudflare Docs — 1.1.1.1 DNS Resolver(مرجع تقني أولي)
- RFC 9114 — HTTP/3(مرجع تقني أولي)