एक ही सबनेट की वेबसाइटें गेटवे की पारदर्शी प्रॉक्सी को बायपास कर सकती हैं
समझाता है कि इंटरनेट अनुरोध उसके लॉग में दिखने के बावजूद एक ही सबनेट का ट्रैफ़िक गेटवे के अवरोधन नियम को क्यों बायपास कर सकता है।
इंटरनेट ब्राउज़िंग गेटवे प्रॉक्सी के लॉग में दिखती है। ऑफ़िस LAN पर मौजूद वेबसाइट नहीं दिखती। URL फ़िल्टर बदलने से पहले तय करें कि LAN अनुरोध गेटवे तक पहुँचा भी था या नहीं।
सीधे जुड़े IPv4 गंतव्य के लिए क्लाइंट गंतव्य का लिंक-लेयर पता हल कर सकता है और स्थानीय सेगमेंट पर उसे भेज सकता है। उसका डिफ़ॉल्ट गेटवे उस पथ पर अपने आप नहीं होता। गेटवे पर कोई पारदर्शी अवरोधन नियम उन पैकेटों को पुनर्निर्देशित नहीं कर सकता जो गेटवे को कभी मिलते ही नहीं।
उदाहरण के लिए, एक ही ऑन-लिंक सबनेट के दो होस्ट किसी स्विच के ज़रिए ट्रैफ़िक का आदान-प्रदान कर सकते हैं जबकि प्रॉक्सी मशीन दूसरे स्विच पोर्ट से जुड़ी हो। केवल उस LAN पर होना प्रॉक्सी को फ़ॉरवर्डिंग बिंदु नहीं बनाता।
इच्छित पथ चुनें
स्पष्ट प्रॉक्सी सेटिंग भाग लेने वाले एप्लिकेशन का अनुरोध प्रॉक्सी को भेज सकती है, भले ही लक्ष्य वेबसाइट स्थानीय हो। बायपास नियम और PAC निर्णय भी देखें: वे निजी नामों या पतों के लिए जानबूझकर DIRECT चुन सकते हैं।
यदि अवरोधन आवश्यक है, तो नेटवर्क को अवरोधन बिंदु वास्तव में पथ में रखना होगा; Linux गेटवे पर स्थानीय और फ़ॉरवर्ड किए गए पैकेट पथ अलग करें। राउटेड सबनेट पृथक्करण या जानबूझकर इनलाइन ब्रिज उपयुक्त डिज़ाइनों में ऐसा कर सकते हैं, पर हर एक फ़ॉरवर्डिंग और विफलता व्यवहार बदलता है। LAN में कहीं और का ब्रिज अपने आप इनलाइन नहीं होता।
एप्लिकेशन प्रोटोकॉल की आवश्यकता अलग रखें। ट्रैफ़िक के डिब्बे से गुज़रने के बाद भी श्रोता को अवरोधन मोड का समर्थन करना चाहिए। पैकेटों को खिसकाना HTTPS को डिक्रिप्ट करने की अनुमति नहीं है और न ही यह गारंटी कि कोई सामान्य SOCKS पोर्ट उन्हें स्वीकार कर सकेगा।
क्लाइंट द्वारा चुना गया मार्ग, स्थानीय सेगमेंट और वास्तविक फ़ॉरवर्डिंग डिवाइस दर्ज करें। प्रॉक्सी लॉग का अनुपस्थित होना लॉगिंग विफलता नहीं बल्कि टोपोलॉजी का सही वर्णन हो सकता है।