એક રેપર ડાઉનલોડરના શૂન્ય એક્ઝિટ કોડને નિરીક્ષિત “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 મળે છે. તેનું રહસ્ય ડિપ્લોયમેન્ટની યોગ્ય પદ્ધતિ દ્વારા પહોંચાડો, અને ખરેખર નિષ્ફળ ગયેલો તબક્કો જણાવો: નકારાયેલ ટનલને અણધારી વેબસાઇટ સ્થિતિ કરતાં અલગ સમારકામની જરૂર પડે છે.

સંબંધિત લેખો