debug_options વિભાગ 29 સાથે Squid 7 પ્રમાણીકરણ ટ્રેસ કરો
ચેલેન્જ, ક્લાયન્ટ પ્રતિસાદ, પ્રમાણીકરણ સહાયક અને ઍક્સેસ-નીતિ નિર્ણયને અનુસરવા માટે મર્યાદિત વિભાગ-29 ડિબગ સત્ર વાપરો.
Squid નો પહેલો 407 પ્રમાણીકરણની શરૂઆત હોઈ શકે છે. કોઈ પ્રયાસ ક્યાં અટકે છે તે શોધવા માટે એક વિનંતી ક્રમને ક્લાયન્ટ, પ્રમાણીકરણ માળખું અને ઍક્સેસ નિર્ણય દ્વારા અનુસરો.
Squid 7 નિદાન સત્રમાં વિભાગ 29 માં પ્રમાણીકરણ ડિબગ સંદેશાઓ હોય છે. કામચલાઉ રૂપરેખાંકન સામાન્ય ચેતવણી સ્તર રાખીને તે વિભાગ વધારી શકે છે:
debug_options ALL,1 29,5અગાઉનું ડિબગ સેટિંગ નોંધો, નિદાન રૂપરેખાંકન લાગુ કરો અને નાનો, ઓળખી શકાય તેવો પ્રયાસ ફરી કરો. રૂપરેખાંકિત cache_log ગંતવ્ય પર ડિબગ આઉટપુટ ઍક્સેસ લોગ સાથે વાંચો.
| શું પુરાવો શોધવો | કયા પ્રશ્નનો જવાબ આપે છે |
|---|---|
| ઓફર કરેલી Proxy-Authenticate સ્કીમ | આ પ્રોક્સીએ ક્લાયન્ટને શું વાપરવા કહ્યું? |
| ક્લાયન્ટનો પ્રમાણીકરણ પ્રતિસાદ | ક્લાયન્ટે ઓફર કરેલી આપલે ચાલુ રાખી? |
| પ્રમાણીકરણ માળખું અથવા સહાયકનું પરિણામ | ખાતું સ્વીકારાયું, નકારાયું કે પ્રોસેસિંગ નિષ્ફળતાથી અવરોધાયું? |
| Squid નો ઍક્સેસ-નીતિ નિર્ણય | તે પ્રમાણીકરણ સ્થિતિ પછી વિનંતીનું શું થયું? |
કેટલીક સ્કીમને અનેક ચેલેન્જ રાઉન્ડ જરૂરી છે. ફક્ત પુનરાવર્તિત 407 એન્ટ્રીઓ એ સાબિત કરતી નથી કે બ્રાઉઝરે સૂચના અવગણી અથવા આપેલો પાસવર્ડ ખોટો હતો.
સહાયકની નિષ્ફળતાઓ માટે રૂપરેખાંકિત સહાયક અને તેના સ્કીમ-વિશિષ્ટ પરિણામ પ્રોટોકોલની તપાસ કરો. શરૂ ન થઈ શકતી પ્રક્રિયા ચાલતા સહાયક દ્વારા ખાતું નકારવાથી અલગ ખામી છે. જો પ્રમાણીકરણ સ્વીકારાયું પણ Squid હજી વિનંતી નકારે, તો અનુરૂપ ઍક્સેસ નિયમો અનુસરો.
ક્રમ સમજાય પછી મૂળ ડિબગ સ્તર પુનઃસ્થાપિત કરો. સંપૂર્ણ સ્તર 9 આઉટપુટ ઘણું મોટું હોઈ શકે; પ્રમાણીકરણ નિદાનને પણ મર્યાદિત હેન્ડલિંગ જોઈએ કારણ કે ખાતાની વિગતો અને અન્ય સંવેદનશીલ સ્થિતિઓ દેખાઈ શકે.