client → local forward proxy → HTTP parent → website

यह कहने के बजाय कि सारा DNS “प्रॉक्सी” का है, विफल हो रहे नाम से शुरू करें:

आवश्यक नामवह हॉप जिसे इसे पाना है
स्थानीय प्रॉक्सी एंडपॉइंटक्लाइंट
HTTP पैरेंट एंडपॉइंटस्थानीय फ़ॉरवर्ड प्रॉक्सी
वेबसाइट एंडपॉइंटपैरेंट, जब वह अंतिम कनेक्शन खोलता है

जब एंडपॉइंट होस्टनाम हों तो ये हॉप अलग-अलग रिज़ॉल्वर उपयोग कर सकते हैं। HTTPS के लिए, फ़ॉरवर्ड प्रॉक्सी CONNECT का गंतव्य होस्ट और पोर्ट पैरेंट को दे सकता है, और पैरेंट अंतिम कनेक्शन बनाता है। मूल क्लाइंट को पहले वेबसाइट हल करने की आवश्यकता नहीं है। सादा HTTP फ़ॉरवर्डिंग भी गंतव्य की जानकारी आगे ले जाती है।

यह वादा नहीं है कि हर नाम के लिए ठीक एक ही मशीन क्वेरी करती है। ACL मूल्यांकन, कैशिंग, नीति और कार्यान्वयन विवरण अतिरिक्त लुकअप करा सकते हैं।

पैरेंट उपलब्ध न हो तो फ़ॉलबैक नीति जाँचें। यदि सीधा पहुँच अनुमत है, तो स्थानीय प्रॉक्सी अपने रिज़ॉल्वर और स्रोत-पता निर्णयों के साथ वेबसाइट की ओर मुँह किए हॉप बन सकता है। केवल पैरेंट कॉन्फ़िगर करना यह सिद्ध नहीं करता कि हर अनुरोध ने उसका उपयोग किया।

विफलता पर, hosts फ़ाइल संपादित करने से पहले वह नाम और प्रक्रिया पहचानें जो उसे हल करने का प्रयास कर रही है। क्लाइंट पक्ष का संपादन हर आगे के निर्णय को ठीक नहीं कर सकता। अंतिम सार्वजनिक स्रोत उस हॉप का है जो वेबसाइट कनेक्शन खोलता है; उस स्रोत को देखना यह मापने के समान नहीं है कि DNS कहाँ हुआ।

संबंधित लेख