समजा एखादा क्लायंट प्रॉक्सी क्रेडेन्शियलशिवाय एक विनंती पाठवतो, आव्हान मिळवतो आणि नंतर यशस्वीपणे पुन्हा प्रयत्न करतो. विनंती लॉगमध्ये दोन नोंदी असू शकतात. पण ॲप वापरणाऱ्या व्यक्तीने एकच पूर्ण झालेली क्रिया अनुभवली.

म्हणूनच TCP_DENIED/407 आणि TCP_TUNNEL/200 मध्ये समान विभागलेला लॉग स्वतःच पन्नास टक्के अयशस्वीता दर सिद्ध करत नाही. आधी ठरवा की नोंदी आव्हान-आणि-पुनःप्रयत्न जोड्या बनवतात का.

तुम्हाला खरोखर महत्त्वाचे असलेले मोजा

मापगणना
प्रमाणीकरण आव्हानेप्रमाणीकरण मागणाऱ्या प्रॉक्सी प्रतिसाद
प्रॉक्सी प्रयत्नमध्यस्थाने नोंदवलेले वैयक्तिक व्यवहार
पूर्ण झालेली कामेइच्छित निकालापर्यंत पोहोचणाऱ्या ॲप क्रिया

वेळेच्या नोंदी, क्लायंट संदर्भ, गंतव्य आणि उपलब्ध कोणताही विनंती ओळखकर्ता यांचा परस्परसंबंध लावा. प्रमाणीकरण न केलेल्या प्रयत्नात नोंदवलेले वापरकर्तानाव नसू शकते, तर त्याच्या यशस्वी पुनःप्रयत्नात असते. एकाच वेळी सुरू असलेली हालचाल म्हणजे केवळ शेजारील ओळी दोन नोंदी एकत्र असल्याचा कमकुवत पुरावा आहेत.

यशस्वी बोगदा यशस्वी वेबसाइट क्रियेपासून वेगळा ठेवा. CONNECT स्वीकारणे बोगदा उभारते; गंतव्य TLS दरम्यान अजूनही अयशस्वी होऊ शकते किंवा नंतर ॲप त्रुटी परत करू शकते.

वारंवार येणारी अंतिम आव्हाने, नंतर कधीही पूर्ण न होणारी कामे, किंवा देवघेवींच्या संख्येत अचानक बदल यांची चौकशी करा. हे त्यांच्या कॉन्फिगरेशनने मागितल्याप्रमाणे नेमके करणाऱ्या स्थिर आव्हान-प्रथम क्लायंटपेक्षा वेगळे आहेत. केवळ डॅशबोर्ड हिरवा करण्यासाठी प्रमाणीकरण दाबणे मोजमाप दुरुस्त करण्याऐवजी सेवा बदलेल.

संबंधित लेख