قد ترى عنوان IP الخاص بالبروكسي في صفحة الفحص وتفترض أن كل الاتصال يمر من نفس المسار. لكن DNS يمكن أن يسلك طريقًا آخر، خصوصًا مع إعدادات نظام التشغيل أو DoH أو نوع Proxy لا يتولى Resolve للأسماء. تسرب DNS لا يعني دائمًا كشف الحساب مباشرة، لكنه يكشف عدم اتساق في تصميم الشبكة ويستحق الفهم والاختبار.
أين يحدث Resolve للاسم؟
قبل الاتصال ب ـexample.com يجب تحويل الاسم إلى IP. هذا التحويل يمكن أن يحدث محليًا على الجهاز، داخل المتصفح عبر DoH، أو عبر البروكسي نفسه حسب النوع والإعداد. إذا خرج HTTP عبر البروكسي لكن DNS محليًا، فأنت تستخدم مسارين مختلفين.
اختبر DNS من داخل نفس البروفايل
لا يكفي فحص DNS على النظام إذا كان كل Profile له إعدادات مختلفة. افتح أداة اختبار من نفس البروفايل والبروكسي، وسجل Resolver والبلد و ASN. قارنها بمسار ال ـIP العام وبالتصميم الذي تتوقعه.
خطوات عملية
- ثبت البروكسي على البروفايل.
- افحص ال ـIP العام.
- شغل DNS leak test من نفس البروفايل.
- سجل Resolver و ASN والموقع.
- كرر الاختبار بعد Restart للتأكد من الثبات.
تمييز التسرب عن النتيجة الطبيعية
رؤية Resolver مختلف عن مزود البروكسي ليست دائمًا خطأ؛ بعض المزودين يستخدمون DNS عام أو Anycast. السؤال هو هل المسار متوقع ومقبول أم أنه DNS المحلي الذي كنت تريد إخفاءه. افهم بنية المزود قبل الحكم.
قائمة مراجعة
- تعرف من يدير ال ـResolver.
- المسار لا يكشف DNS محلي غير مقصود.
- DoH مضبوط حسب السياسة.
- النتيجة ثابتة بعد إعادة التشغيل.
- اختبار البروكسي يتم من نفس Profile.
الإصلاح يجب أن يكون في طبقة السبب
إذا كان السبب هو Local DNS مع SOCKS، فعّل Remote DNS في العميل المناسب. إذا كان DoH يتجاوز السياسة، اضبط إعداد المتصفح. لا تحاول إخفاء النتيجة في صفحة الاختبار؛ أصلح مسار Resolve نفسه.
سيناريو تطبيقي قبل الاعتماد
افترض أن البروكسي سيعمل في جلسة إنتاج حقيقية لا في اختبار IP مدته ثوانٍ. المطلوب معرفة كيف يتصرف مع الزمن وتحت عدة طلبات وعند انقطاع قصير. في موضوع «DNS Leak مع البروكسي: كيف يحدث وكيف تختبره»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ ب ـ1- ثبت البروكسي على البروفايل.، 2- افحص ال ـIP العام.، 3- شغل DNS leak test من نفس البروفايل.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.
كيف تقيس نجاح التجربة؟
المؤشرات الأهم هي معدل النجاح، P50/P95 للزمن، ثبات العنوان عند الحاجة، دقة الموقع، وسلوك DNS أو التدوير. أي قرار يعتمد على رقم سرعة واحد سيكون ناقصًا. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: SOCKS5 يمكن أن يدعم Remote DNS حسب العميل.؛ HTTP proxy قد يستقبل hostname مباشرة في بعض الطلبات.؛ DoH داخل المتصفح قد يتجاوز Resolver النظام.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.
عند الفشل: ماذا تراجع أولًا؟
عند فشل الطلب لا تغيّر المزود أو ال ـIP فورًا. صنف الفشل: DNS، مصادقة، timeout، reset، أو استجابة من الوجهة. هذا يمنعك من علاج عرضٍ شبكي بإجراء لا علاقة له بالسبب. عند التحقيق استخدم هذه القائمة كحد أدنى: تعرف من يدير ال ـResolver.؛ المسار لا يكشف DNS محلي غير مقصود.؛ DoH مضبوط حسب السياسة.؛ النتيجة ثابتة بعد إعادة التشغيل.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.
متى تعتمد القرار على نطاق أوسع؟
قرار الاعتماد لا يجب أن يعتمد على أن التجربة «عملت مرة». في «DNS Leak مع البروكسي: كيف يحدث وكيف تختبره» اعتبر الحل جاهزًا عندما تستطيع إعادة نفس السيناريو بنتيجة متقاربة، ويفهم شخص آخر خطوات الاختبار وحدود النتيجة، وتعرف ماذا ستفعل لو فشلت الحالة الطبيعية. لو لم تتحقق هذه الشروط، احتفظ بالحل كتجربة أو إعداد مبدئي ولا تحوله إلى Default لكل الحسابات أو المهام.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…