प्रोक्सी मनिटरको स्थिति र एक्जिट कोडको व्याख्या
प्रोक्सीमार्फत हुने वेबसाइट जाँचमा आदेश कार्यान्वयन, HTTP नतिजा र प्रमाणपत्र प्रमाणीकरण छुट्टाछुट्टै रिपोर्ट गर्नुहोस्।
एउटा र्यापरले डाउनलोडरको शून्य एक्जिट कोडलाई अवलोकित “HTTP 200 OK” मा बदल्न सक्दैन। प्रत्येक तहले वास्तवमा के रिपोर्ट गर्यो लेख्नुहोस्:
| फाँट | उत्तर दिने प्रश्न |
|---|---|
| उपकरण वा प्लगइन एक्जिट | जाँच चल्यो कि, र कुन असफलता वर्ग रिपोर्ट गर्यो? |
| प्रोक्सी वार्ता | फर्वार्डिङ वा अनुरोध गरिएको सुरुङ स्वीकृत भयो? |
| मूल स्थिति र अपेक्षित सामग्री | अनुप्रयोगले इच्छित नतिजा फर्कायो? |
| TLS प्रमाणीकरण | कन्फिगर गरिएका पहिचान जाँच सफल भए? |
HTTP त्रुटि प्रतिक्रियापछि पनि curl सामान्यतया शून्य फर्काउन सक्छ। यसका fail विकल्पहरूले एक्जिट व्यवहार बदल्छन्, तर असफलता एक्जिटले अझै स्थिति अद्वितीय रूपमा पहिचान गर्दैन। Wget का एक्जिट मान पनि वर्ग हुन्: प्रमाणीकरण असफलता HTTP 401 का लागि समर्पित मान होइन, र सर्भर-त्रुटि वर्गले त्यसभित्रका हरेक प्रतिक्रिया पहिचान गर्दैन। 401 अपेक्षा गर्ने जाँचले त्यो प्रतिक्रिया अवलोकन गर्नैपर्छ।
प्रोक्सी अन्त्यबिन्दु र वेबसाइटको नाम अलग राख्नुहोस्। HTTP-प्रोक्सी जाँचको TCP सहयात्री प्रोक्सी हो; CONNECT ले गन्तव्यको नाम दिन्छ, जसको TLS सत्र त्यसपछि सुरुङभित्र चल्छ। HTTPS प्रोक्सीका लागि बाहिरी प्रोक्सीमाथिको विश्वास अर्को प्रमाणपत्र जाँच हो।
SSL फ्ल्यागलाई प्रमाणीकरण मान्नुअघि प्लगइनको ग्यारेन्टी जाँच्नुहोस्। Monitoring Plugins ले check_http लाई check_curl को पक्षमा हटाउँदैछ। check_http को कागजातले चेतावनी दिन्छ कि केवल SSL छान्दा होस्टनाम वा जारीकर्ताको विश्वास प्रमाणित हुँदैन; check_curl को कागजातीय verify-peer विकल्पले त्यो प्रमाणीकरण समावेश गर्छ।
इच्छित प्रमाणित मार्ग पनि प्रयोग गर्नुहोस्। पोर्ट प्रोब हरियो रहन सक्छ जबकि सञ्चालन खाताले 407 पाउँछ। यसको गोप्यता परिनियोजनको उपयुक्त संयन्त्रबाट पुर्याउनुहोस्, र वास्तवमै असफल भएको चरण रिपोर्ट गर्नुहोस्: अस्वीकृत सुरुङलाई अप्रत्याशित वेबसाइट स्थितिभन्दा फरक मर्मत चाहिन्छ।