સ્ટેટસ સંદેશ કહે છે “Resolving host in proxy script,” પણ પ્રોક્સી સર્વર બદલવાથી ભાગ્યે જ ફેર પડે છે. તે ઉપયોગી સંકેત છે: બ્રાઉઝર કદાચ હજી નક્કી કરી રહ્યું છે કે વિનંતી ક્યાં મોકલવી.

PAC ફાઇલ DNS-આધારિત તપાસ કરી શકે છે. જો તે તપાસ અગમ્ય રિઝોલ્વરની રાહ જુએ અથવા વારંવાર બિનજરૂરી પ્રશ્નો પૂછે, તો પસંદ કરેલ પ્રોક્સીને કંઈ મળે તે પહેલાં પૃષ્ઠ લોડ થવું થંભી શકે છે.

1. અટકાવ ક્યાં છે તે શોધો

એક અસરગ્રસ્ત URL માટે નક્કી કરો કે વિલંબ PAC ફાઇલ મેળવતી વખતે, તેનું મૂલ્યાંકન કરતી વખતે, કે પરત મળેલ પ્રોક્સી સાથે જોડાતી વખતે થાય છે. ખાલી પ્રોક્સી એક્સેસ લોગ પ્રથમ બે તબક્કા સાથે સુસંગત છે; તે સાબિત કરતું નથી કે બ્રાઉઝરે સીધો માર્ગ વાપર્યો.

પછી તપાસો કયા નિયમોને DNSની જરૂર છે. Microsoftની PAC કામગીરી માર્ગદર્શિકા બિનજરૂરી DNS-આધારિત કામ ટાળવાની સલાહ આપે છે. હોસ્ટનામ સમાનતા તપાસને તે હોસ્ટનામ ઉકેલીને સબનેટ તપાસવા જેટલી જ માહિતીની જરૂર નથી.

2. બિનજરૂરી DNS કામ દૂર કરો

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

ઉપર બિનશરતી DIRECT રિટર્ન ઉમેરીને ધીમી સ્ક્રિપ્ટ “સુધારશો” નહીં. તે વિલંબ સાથે રાઉટિંગ નિર્ણય પણ દૂર કરે છે.

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

સંબંધિત લેખો