أعطال DNS في سلسلة وسيط HTTP: أي قفزة تحل الاسم؟
افصل بين الوصول إلى الوسيط المحلي وتحليل الوسيط الأب وتحليل الموقع عند تشخيص وسيط أمامي متسلسل.
client → local forward proxy → HTTP parent → websiteابدأ بالاسم الفاشل بدلًا من القول إن كل DNS ملك لـ«الوسيط»:
| الاسم المطلوب | القفزة التي تحتاج إلى الوصول إليه |
|---|---|
| نقطة نهاية الوسيط المحلي | العميل |
| نقطة نهاية الوسيط الأب عبر HTTP | الوسيط الأمامي المحلي |
| نقطة نهاية الموقع | الوسيط الأب عندما يفتح الاتصال النهائي |
يمكن لتلك القفزات استخدام مُحلّلات مختلفة عندما تكون نقاط النهاية أسماء مضيفين. في HTTPS، يمكن للوسيط الأمامي تمرير اسم مضيف ومنفذ وجهة CONNECT إلى الوسيط الأب، الذي ينفّذ الاتصال النهائي. ولا يلزم أن يحل العميل الأصلي الموقع أولًا. كما تنقل إعادة التوجيه العادية عبر HTTP معلومات الوجهة إلى الأمام.
هذا ليس وعدًا بأن جهازًا واحدًا بالضبط يستعلم عن كل اسم. فتقييم ACL والتخزين المؤقت والسياسة وتفاصيل التنفيذ قد تتسبب في عمليات بحث إضافية.
افحص سياسة الاحتياط عندما يكون الوسيط الأب غير متاح. وإذا كان الوصول المباشر مسموحًا، فقد يصبح الوسيط المحلي هو القفزة المواجهة للموقع، بقراراته الخاصة للمُحلّل وعنوان المصدر. مجرد تهيئة وسيط أب لا يثبت أن كل طلب استخدمه.
عند حدوث عطل، حدّد الاسم والعملية التي تحاول حله قبل تعديل ملف hosts. فلا يمكن لتعديل من جهة العميل أن يصلح كل قرار لاحق. المصدر العام النهائي يخص القفزة التي تفتح اتصال الموقع؛ ورصد ذلك المصدر ليس مثل قياس أين حدث DNS.