HTTP પ્રોક્સી ચેઇનમાં DNS નિષ્ફળતાઓ: કયો હોપ નામ ઉકેલે છે?
ચેઇન કરેલા ફોરવર્ડ પ્રોક્સીનું નિદાન કરતી વખતે સ્થાનિક પ્રોક્સી સુધી પહોંચવું, પેરેન્ટ ઉકેલવું અને વેબસાઇટ ઉકેલવું અલગ કરો.
client → local forward proxy → HTTP parent → websiteબધા DNS “પ્રોક્સી”ના છે એમ કહેવાને બદલે નિષ્ફળ થતા નામથી શરૂ કરો:
| જરૂરી નામ | જે હોપે તે સુધી પહોંચવું છે |
|---|---|
| સ્થાનિક પ્રોક્સી એન્ડપોઇન્ટ | ક્લાયન્ટ |
| HTTP પેરેન્ટ એન્ડપોઇન્ટ | સ્થાનિક ફોરવર્ડ પ્રોક્સી |
| વેબસાઇટ એન્ડપોઇન્ટ | પેરેન્ટ જ્યારે અંતિમ કનેક્શન ખોલે છે |
એન્ડપોઇન્ટ હોસ્ટનામ હોય ત્યારે તે હોપ વિવિધ રિઝોલ્વર વાપરી શકે છે. HTTPS માટે, ફોરવર્ડ પ્રોક્સી CONNECTનું ગંતવ્ય હોસ્ટ અને પોર્ટ પેરેન્ટને આપી શકે છે, જે અંતિમ કનેક્શન બનાવે છે. મૂળ ક્લાયન્ટને પહેલા વેબસાઇટ ઉકેલવાની જરૂર નથી. સાદું HTTP ફોરવર્ડિંગ પણ ગંતવ્યની માહિતી આગળ લઈ જાય છે.
આ એવું વચન નથી કે દરેક નામ માટે બરાબર એક જ મશીન પૂછે છે. ACL મૂલ્યાંકન, કેશિંગ, નીતિ અને અમલીકરણની વિગતો વધારાની શોધ કરાવી શકે છે.
પેરેન્ટ ઉપલબ્ધ ન હોય ત્યારે ફોલબેક નીતિ તપાસો. સીધો ઍક્સેસ મંજૂર હોય તો સ્થાનિક પ્રોક્સી પોતાના રિઝોલ્વર અને સ્રોત-સરનામાના નિર્ણયો સાથે વેબસાઇટ તરફનું હોપ બની શકે છે. ફક્ત પેરેન્ટ ગોઠવવાથી સાબિત થતું નથી કે દરેક વિનંતીએ તેનો ઉપયોગ કર્યો.
નિષ્ફળતા વખતે hosts ફાઇલ સંપાદિત કરતા પહેલા નામ અને તેને ઉકેલવા માગતી પ્રક્રિયા ઓળખો. ક્લાયન્ટ બાજુનું સંપાદન પછીના દરેક નિર્ણયને સુધારી શકતું નથી. અંતિમ જાહેર સ્રોત તે હોપનો છે જે વેબસાઇટ કનેક્શન ખોલે છે; તે સ્રોતનું નિરીક્ષણ DNS ક્યાં થયું તે માપવા જેટલું જ નથી.