عند فشل تحميل موقع داخل متصفح مخصص، القفز مباشرة إلى تغيير DNS أو تبديل البروكسي قد يضيف متغيرات جديدة ويصعّب التشخيص. الأفضل تقسيم الاتصال إلى مراحل: حل الاسم، الوصول إلى الوسيط إن وُجد، إنشاء TCP/TLS، ثم إرسال الطلب. معرفة آخر مرحلة نجحت تكشف غالبًا هل السبب DNS أم Proxy أم Firewall.
بصمة DNS Failure
فشل DNS يحدث قبل وجود عنوان مقصد قابل للاتصال. العلامات المعتادة تشمل NXDOMAIN أو timeout في resolver أو ERR_NAME_NOT_RESOLVED. اختبر lookup خارج المتصفح ثم داخل مسار البروفايل. إذا كان البروكسي يحل الأسماء عن بعد، يجب أيضًا اختبار resolver من جهة البروكسي لا من الجهاز فقط.
بصمة Proxy Failure
قد ينجح DNS محليًا لكن يفشل الاتصال بال ـproxy نفسه، أو يرد الوسيط ب ـ407، أو يرفض CONNECT، أو ينتهي ال ـtunnel. هنا ستجد عنوان البروكسي معروفًا ومحاولة اتصال واضحة. قارن direct mode بنفس الوجهة، واختبر endpoint والبورت و credentials والسياسة الخاصة بالنطاق.
بصمة Firewall Block
الجدار الناري قد يسمح بال ـDNS ثم يمنع TCP/UDP أو منفذًا محددًا أو عملية بعينها. قد ترى timeout بدل رفض صريح. اختبر عنوان IP ومنفذًا معروفًا، وقارن تطبيقًا آخر على الجهاز. إذا كان الحظر process-based فقد ينجح curl ويفشل Electron، لذلك يجب توثيق اسم العملية والسياسات الأمنية.
ابنِ Matrix بدل اختبار واحد
أنشئ مصفوفة صغيرة: direct/proxy، domain/IP، TCP/UDP، وبروفايل سليم/متأثر. لا تحتاج عشرات الأدوات؛ تحتاج متغيرًا واحدًا يتغير في كل مرة. النتيجة التي تتغير مع متغير معين هي أفضل دليل على الطبقة المسؤولة.
خطوات عملية
- اختبر DNS للاسم.
- اختبر الوصول إلى proxy endpoint.
- اختبر TCP/TLS للوجهة.
- اختبر direct مقابل proxy.
- قارن بروفايلين بنفس الظروف.
احتفظ بالدليل قبل الإصلاح
سجل الخطأ والوقت والمسار وال ـproxy وال ـDNS المستخدم. بعد الإصلاح أعد نفس المصفوفة بدل الاكتفاء بأن الصفحة فتحت مرة واحدة. هذا يحول الحادثة إلى regression test يمكن استخدامه في الإصدارات القادمة.
اجمع الدليل قبل تغيير الإعدادات
في «فرق DNS Failure عن Proxy Failure عن Firewall Block في التشخيص» اجمع timestamp وكود الخطأ والمكوّن والبروفايل ومسار الشبكة قبل أي تعديل. بعد ذلك قارن حالة سليمة بحالة متأثرة مع تغيير عامل واحد فقط، مثل proxy أو extension أو policy. إذا اختفى الخطأ، أعد العامل مرة أخرى للتأكد من السببية بدل الاكتفاء بتحسن مؤقت. احفظ النتيجة في checklist أو test يمكن تشغيله بعد الإصلاح. التشخيص الأمني الجيد يقلل البيانات التي يجمعها، لكنه يحتفظ بما يكفي لإثبات أين بدأت المشكلة وأين انتهت دون تخزين cookies أو tokens أو محتوى حسابات.
قائمة مراجعة
- وقت وكود خطأ واضحان.
- مقارنة سليم/متأثر.
- تغيير عامل واحد.
- إعادة العامل لإثبات السببية.
معيار القبول قبل الإغلاق
حدد شرط إغلاق الحادثة قبل الإصلاح: سبب مثبت، إصلاح ضيق، واختبار regression يعيد الحالة القديمة ويميزها عن السليمة. لا تحذف السجلات أو تعيد ضبط البروفايل قبل التقاط الدليل الضروري، ولا تسجل أسرارًا بحجة تسهيل التشخيص.
قائمة مراجعة
- نتيجة قابلة لإعادة الاختبار.
- سبب موثق لا مجرد اختفاء العرض.
- Regression test بعد الإصلاح.
حالة فشل يجب اختبارها
في «فرق DNS Failure عن Proxy Failure عن Firewall Block في التشخيص» أعد إنتاج الخطأ مرة تحت logging عادي ومرة تحت logging تشخيصي مؤقت، ثم قارن هل المعلومات الإضافية ساعدت فعلًا. إذا لم تضف قيمة، لا تحتفظ بها في الإنتاج. الهدف أن يكون كل حقل في السجل مرتبطًا بسؤال تشخيصي واضح، لا جمع بيانات احتياطيًا.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…