مين بيحل اسم الموقع؟ تشخيص اختلاف مسار DNS بين تطبيقين

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

ارسم مسار الاسم قبل مسار الصفحة

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

ابنِ مقارنة لا تخدعها الذاكرة المؤقتة

استخدام اسم سبق فتحه قد يجعل النتيجة مرتبطة بالذاكرة المؤقتة بدل المسار الذي تريد رصده. جهّز أسماء اختبار جديدة ضمن نطاق تملك صلاحية استخدامه، أو وسيلة اختبار مأذون بها تتيح متابعة الاستعلام. لا تعتمد على غياب طلب جديد باعتباره نجاحًا تلقائيًا. قارن التطبيقين في ظروف متقاربة، وسجّل ما استطعت رؤيته فعلًا، مع ترك خانة صريحة لأي جزء لا تملك سجلاته.

اعزل أثر DoH عن تغيير البروكسي

قد يغير DNS عبر HTTPS داخل المتصفح المسار المتوقع؛ ولهذا لا تغيّر البروكسي و DoH معًا ثم تنسب النتيجة لأحدهما. ابدأ بالإعداد الموجود وسجله، ثم غيّر عنصرًا واحدًا داخل تجربة مؤقتة قابلة للرجوع. أعد نفس المقارنة باستخدام اسم جديد. لو اختلف التطبيقان، فالنتيجة تخص إعداد كل تطبيق، ولا يصح تعميمها على النظام كله أو على بروتوكول البروكسي وحده.

اكتب نتيجة محدودة بالدليل المتاح

اختبار IP وحده لا يكشف مسار DNS، كما أن DNS leak و WebRTC leak و IP leak ليست مسميات لنتيجة واحدة. اكتب تقريرًا بسيطًا فيه المتوقع والمرصود ومصدر الرصد، ثم صنّف الحالة إلى متطابقة أو مختلفة أو غير محسومة. إذا لم تتوفر سجلات كافية، اذكر ذلك بدل إعلان أن الاتصال خالٍ من التسريب. بهذه الصياغة تقدر تعيد الفحص لاحقًا وتعرف هل الاختلاف سببه تطبيق بعينه أو إعداد تغيّر.