Squid retry_on_error: स्थिति कोड र वैकल्पिक मार्गहरू

Squid मा retry_on_error नामको विकल्प छ, तर नाम यसको उपयोगी व्याख्याभन्दा फराकिलो छ। यसको अर्थ प्रत्येक असफल अनुरोध पृष्ठ काम नगरेसम्म असीमित रूपमा दोहोरिन्छ भन्ने होइन।

यो निर्देश समर्थन गर्ने संस्करणहरूमा यो पूर्वनिर्धारित रूपमा बन्द छ। कागजात गरिएको पुनरावृत्ति सूची 403, 500, 501, 502, 503 र 504 हो, र यसले अनुरोधलाई अर्को काम गर्ने गन्तव्यमार्फत प्रयास गर्छ। वैकल्पिक फर्वार्डिङ मार्गहरू भएको पदानुक्रममा यो विशेष रूपमा सान्दर्भिक छ। यो केवल एउटै सकेटबाट एउटै सर्भरमा समयबद्ध पुनःप्रयास मात्र होइन।

पहिले असफलताको नाम दिनुहोस्

प्रोक्सीमा जोडिँदा अस्वीकार, प्रोक्सी प्रमाणीकरण असफलता, मूलबाट HTTP त्रुटि र डेलिभरी सुरु भएपछि काटिएको प्रतिक्रियाले एउटै पुनःप्रयास अवसर दिँदैनन्। एउटा सेटिङले चारैलाई एउटै तरिकाले हेर्ला भन्ने अपेक्षा नगर्नुहोस्।

निजी निकासका लागि वैकल्पिक मार्ग स्वीकार्य छ कि छैन पनि निर्धारण गर्नुहोस्। अर्को अभिभावकसँग अर्को सार्वजनिक स्रोत ठेगाना, प्रमाणीकरण नीति वा सञ्जाल स्थान हुन सक्छ। त्यो विकल्पमार्फत सफलता पहिलो अभिभावक छान्नुको कारण उल्लंघन गर्न सक्छ।

अनुप्रयोग सञ्चालनले अर्को चिन्ता ल्याउँछ: अनुरोध दोहोर्याउँदा यसको प्रभाव पनि दोहोरिन सक्छ। क्लाइन्ट र सर्भरलाई उपयुक्त पुनःप्रयास अर्थशास्त्र चाहिन्छ, विशेष गरी डेटा सिर्जना वा परिवर्तन गर्ने सञ्चालनका लागि। प्रोक्सी सेटिङ अनिश्चित परिणामहरूको अनुप्रयोग-स्तरीय व्यवस्थापनको विकल्प होइन।

तपाईंको ठ्याक्कै संस्करणका लागि निर्देश पढ्नुहोस्; सन्दर्भले उपलब्धता र पूर्वनिर्धारित व्यवहार सूचीबद्ध गर्छ। साथै अनुरोधको समयसीमा र प्रयोगकर्ताले देख्ने कुल प्रतीक्षा पनि ध्यानमा राख्नुहोस्। थप फर्वार्डिङ प्रयासले राम्रो नतिजा नदिई बाँकी समय खर्च गर्न सक्छ।

रोकिएर हुने असफलताहरूको अनुसन्धान गर्दा स्थिति, छानिएको अभिभावक वा गन्तव्य र प्रयासको क्रम रेकर्ड गर्नुहोस्। नत्र पुनरावृत्तिले दोहोरिने राउटिङ समस्यालाई सामान्य रूपमा ढिलो वेबसाइटजस्तो देखाउन सक्छ र वास्तवमा असफल भएको मार्ग लुकाउन सक्छ।