Squid में पैरेंट घोषित करने भर से हर फ़ॉरवर्ड अनुरोध का उसे इस्तेमाल करना अनिवार्य नहीं होता। सीधा रास्ता नीति तोड़ता हो तो यह शर्त साफ़ कॉन्फ़िगर करें और पैरेंट उपलब्ध न हो तब का व्यवहार जाँचें।

Squid 6.13 का यह उदाहरण एक पैरेंट तय करता है और एक क्लाइंट स्रोत के लिए मूल सर्वर को सीधा फ़ॉरवर्ड करना रोकता है:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

दोनों पते उदाहरण के लिए हैं। सार्वजनिक HTTP पैरेंट की अनुमति वाले नियंत्रित अपस्ट्रीम परीक्षण में HTTP प्रॉक्सी सूची से पता लें। अलग http_access नीति बनाए रखें जो सिर्फ ज़रूरी क्लाइंट स्वीकार करती है। रूटिंग नियम क्लाइंट को प्रॉक्सी इस्तेमाल करने का अधिकार नहीं देता।

मौजूदा रूटिंग नियम जाँचें

no-query इस peer को ICP क्वेरी बंद करता है। शून्य peer का क्वेरी पोर्ट है, उसका HTTP लिसनर नहीं। क्लाइंट की ओर का लिसनर और पहुँच नियम अलग रहते हैं।

यह ब्लॉक जोड़ने से पहले मौजूदा always_direct सेटिंग और दूसरे peer चयन देखें। always_direct में मैच मना करना अपने आप पैरेंट अनिवार्य नहीं करता। स्पष्ट never-direct नियम चुने क्लाइंट के लिए यह शर्त बताता है।

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

रास्ता और विफलता व्यवहार जाँचें

नियंत्रित गंतव्य लें और गंतव्य पर देखी बातों के साथ एक्सेस लॉग की hierarchy जानकारी देखें। अंतिम HTTP स्टेटस अकेले नहीं बताता कि Squid ने पैरेंट इस्तेमाल किया या सीधा रास्ता।

रखरखाव परीक्षण में पैरेंट अनुपलब्ध करें और वही बिना कैश का अनुरोध दोहराएँ। नीति सीधा फ़ॉरवर्ड रोकती है तो ट्रांज़ैक्शन को दूसरे रास्ते मूल तक पहुँचने के बजाय विफल होना चाहिए। सिर्फ अपने नियंत्रण की सेवाओं पर ऐसा करें और बाद में इच्छित कॉन्फ़िगरेशन बहाल करें।

संबंधित लेख