స్థితి సందేశం “Resolving host in proxy script” అని చెబుతుంది, కానీ ప్రాక్సీ సర్వర్లను మార్చడం పెద్దగా తేడా చేయదు. ఇది ఉపయోగకరమైన సూచన: అభ్యర్థనను ఎక్కడికి పంపాలో బ్రౌజర్ ఇంకా నిర్ణయిస్తూ ఉండవచ్చు.

PAC ఫైల్ DNS-ఆధారిత తనిఖీలను చేయగలదు. ఆ తనిఖీలు చేరుకోలేని రిజాల్వర్ కోసం వేచి ఉంటే లేదా అనవసరమైన ప్రశ్నలను పదేపదే అడిగితే, ఎంచుకున్న ప్రాక్సీ ఏమీ పొందకముందే పేజీ లోడ్ ఆగిపోవచ్చు.

1. ఆగే స్థలాన్ని గుర్తించండి

ప్రభావితమైన ఒక URL కోసం, ఆలస్యం PAC ఫైల్‌ను తీసుకునేటప్పుడు, దాన్ని అంచనా వేసేటప్పుడు, లేదా తిరిగి ఇచ్చిన ప్రాక్సీకి కనెక్ట్ అయ్యేటప్పుడు జరుగుతుందో లేదో నిర్ణయించండి. ఖాళీ ప్రాక్సీ యాక్సెస్ లాగ్ మొదటి రెండు దశలతో సరిపోతుంది; బ్రౌజర్ నేరుగా మార్గాన్ని ఉపయోగించిందని అది నిరూపించదు.

తర్వాత ఏ నియమాలకు DNS అవసరమో తనిఖీ చేయండి. Microsoft యొక్క PAC పనితీరు మార్గదర్శకాలు అనవసరమైన DNS-ఆధారిత పనిని నివారించమని సూచిస్తాయి. హోస్ట్‌నేమ్ సమానత్వ తనిఖీకి ఆ పేరును పరిష్కరించి సబ్‌నెట్‌ను తనిఖీ చేయడానికి అవసరమైన అదే సమాచారం అవసరం లేదు.

2. అనవసరమైన DNS పనిని తొలగించండి

తెలిసిన హోస్ట్‌నేమ్ మినహాయింపులు విస్తృత చిరునామా-ఆధారిత తనిఖీలకు ముందే నిర్ణయించగలరు. మిగిలిన విధానానికి నిజంగా దాని చిరునామా అవసరమైనప్పుడే పేరును పరిష్కరించండి. తర్వాతి అనేక షరతులకు ఒకే విలువ అవసరమైతే ఫలితాన్ని లోకల్ వేరియబుల్‌లో ఉంచండి.

పైన షరతులు లేని DIRECT రిటర్న్‌ను జోడించి నెమ్మదైన స్క్రిప్ట్‌ను “సరిచేయ” వద్దు. అది ఆలస్యంతో పాటు రూటింగ్ నిర్ణయాన్ని కూడా తొలగిస్తుంది.

మెషీన్-నిర్దిష్ట DNS పరిష్కారాలకు రుజువు అవసరం. ఫైల్ షేరింగ్‌ను ప్రారంభించడం లేదా ప్రతి ల్యాప్‌టాప్ hosts ఫైల్‌ను తిరిగి రాయడం నెమ్మదైన రూటింగ్ స్క్రిప్ట్‌కు తప్పుడు మొదటి స్పందన. ప్రభావిత నెట్‌వర్క్‌లో రిజాల్వర్ మరియు హోస్ట్‌నేమ్ ప్రవర్తనను తనిఖీ చేయండి, ముఖ్యంగా నెట్‌వర్క్ మార్పు తర్వాత, మరియు PAC-ను దాని నిజమైన నిర్ణయ మార్గం కోరిన చోట మాత్రమే మార్చండి.

సంబంధిత వ్యాసాలు