ધારો કે ક્લાયન્ટ પ્રોક્સી ઓળખપત્રો વિના એક વિનંતી મોકલે છે, ચેલેન્જ મેળવે છે અને સફળતાપૂર્વક ફરી પ્રયાસ કરે છે. વિનંતી લોગમાં બે એન્ટ્રીઓ હોઈ શકે છે. પરંતુ એપ્લિકેશન વાપરનાર વ્યક્તિએ એક જ પૂર્ણ થયેલી ક્રિયા અનુભવી છે.

તેથી TCP_DENIED/407 અને TCP_TUNNEL/200 વચ્ચે સમાન રીતે વિભાજિત લોગ પોતાની રીતે પંચાસ ટકા નિષ્ફળતા દર સિદ્ધ કરતું નથી. પહેલા નક્કી કરો કે એન્ટ્રીઓ ચેલેન્જ-અને-ફરી-પ્રયાસ જોડ બનાવે છે કે નહીં.

તમને ખરેખર જેની પરવા છે તે ગણો

માપગણતરી
પ્રમાણીકરણ ચેલેન્જપ્રમાણીકરણ માંગતા પ્રોક્સી પ્રતિભાવો
પ્રોક્સી પ્રયાસોમધ્યસ્થ દ્વારા નોંધાયેલા વ્યક્તિગત વ્યવહારો
પૂર્ણ થયેલા કાર્યોઇચ્છિત પરિણામ સુધી પહોંચતી એપ્લિકેશન ક્રિયાઓ

સમયછાપ, ક્લાયન્ટ સંદર્ભ, ગંતવ્ય અને ઉપલબ્ધ કોઈપણ વિનંતી ઓળખકર્તાને સહસંબંધિત કરો. પ્રમાણીકરણ વગરના પ્રયાસમાં નોંધાયેલું વપરાશકર્તાનામ ન હોઈ શકે, જ્યારે તેના સફળ ફરી-પ્રયાસમાં હોય છે. એકસાથેની પ્રવૃત્તિ એટલે કે ફક્ત નજીકની લાઇનો બે એન્ટ્રી સાથે હોવાનો નબળો પુરાવો છે.

સફળ ટનલને સફળ વેબસાઇટ ક્રિયાથી અલગ રાખો. CONNECT સ્વીકાર ટનલ સ્થાપે છે; ગંતવ્ય હજી પણ TLS દરમિયાન નિષ્ફળ થઈ શકે છે અથવા પછી એપ્લિકેશન ભૂલ પરત કરી શકે છે.

વારંવાર આવતા અંતિમ ચેલેન્જ, પછીથી ક્યારેય પૂર્ણ ન થતાં કાર્યો, અથવા વિનિમયની સંખ્યામાં અચાનક ફેરફારની તપાસ કરો. આ સ્થિર ચેલેન્જ-પ્રથમ ક્લાયન્ટ જે તેના રૂપરેખાંકન મુજબ બરાબર કરે છે તેનાથી અલગ છે. ફક્ત ડેશબોર્ડ વધુ લીલું કરવા પ્રમાણીકરણ દબાવવું માપ સુધારવાને બદલે સેવા બદલી નાખશે.

સંબંધિત લેખો