रॅपर डाउनलोडरच्या शून्य एक्झिट कोडचे निरीक्षित “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 मिळते. त्याचे रहस्य डिप्लॉयमेंटच्या योग्य यंत्रणेने पोहोचवा, आणि प्रत्यक्षात अयशस्वी झालेला टप्पा नोंदवा: नाकारलेल्या टनेलला अनपेक्षित वेबसाइट स्थितीपेक्षा वेगळी दुरुस्ती लागते.

संबंधित लेख