“Resolving Host in Proxy Script” ൽ കുടുങ്ങിയോ? PAC ഫയൽ നോക്കൂ

സ്റ്റാറ്റസ് സന്ദേശം “Resolving host in proxy script” എന്ന് പറയുന്നു, പക്ഷേ പ്രോക്സി സെർവറുകൾ മാറ്റുന്നത് വലിയ വ്യത്യാസം ഉണ്ടാക്കുന്നില്ല. ഇത് ഉപകാരപ്രദമായ സൂചനയാണ്: അഭ്യർത്ഥന എവിടേക്ക് അയക്കണം എന്ന് ബ്രൗസർ ഇപ്പോഴും തീരുമാനിക്കുകയായിരിക്കാം.

PAC ഫയലിന് DNS-ആശ്രിത പരിശോധനകൾ നടത്താം. ആ പരിശോധനകൾ ലഭ്യമല്ലാത്ത റിസോൾവറിനായി കാത്തിരിക്കുകയോ ആവശ്യമില്ലാത്ത ചോദ്യങ്ങൾ വീണ്ടും വീണ്ടും ചോദിക്കുകയോ ചെയ്താൽ, തിരഞ്ഞെടുത്ത പ്രോക്സിക്ക് ഒന്നും ലഭിക്കുന്നതിന് മുമ്പ് പേജ് ലോഡ് നിലയ്ക്കാം.

1. തടസ്സം എവിടെയെന്ന് കണ്ടെത്തുക

ഒരു ബാധിത URL-ന്, കാലതാമസം PAC ഫയൽ എടുക്കുമ്പോഴോ, അത് വിലയിരുത്തുമ്പോഴോ, തിരികെ നൽകിയ പ്രോക്സിയിലേക്ക് കണക്ട് ചെയ്യുമ്പോഴോ ഉണ്ടാകുന്നുവെന്ന് നിർണ്ണയിക്കുക. ശൂന്യമായ പ്രോക്സി ആക്സസ് ലോഗ് ആദ്യ രണ്ട് ഘട്ടങ്ങളുമായി യോജിക്കുന്നു; ബ്രൗസർ നേരിട്ടുള്ള പാത ഉപയോഗിച്ചുവെന്ന് അത് തെളിയിക്കുന്നില്ല.

തുടർന്ന് ഏത് നിയമങ്ങൾക്കാണ് DNS വേണ്ടതെന്ന് പരിശോധിക്കുക. Microsoft-ന്റെ PAC പ്രകടന മാർഗ്ഗനിർദ്ദേശങ്ങൾ ആവശ്യമില്ലാത്ത DNS-ആശ്രിത ജോലി ഒഴിവാക്കാൻ ശുപാർശ ചെയ്യുന്നു. ഹോസ്റ്റ്നെയിം തുല്യതാ പരിശോധനയ്ക്ക് ആ ഹോസ്റ്റ്നെയിം പരിഹരിച്ച് സബ്നെറ്റ് പരിശോധിക്കുന്നതിന് വേണ്ട അതേ വിവരങ്ങൾ ആവശ്യമില്ല.

2. ആവശ്യമില്ലാത്ത DNS ജോലി നീക്കം ചെയ്യുക

അറിയപ്പെടുന്ന ഹോസ്റ്റ്നെയിം ഒഴിവുകൾ വിശാലമായ വിലാസാധിഷ്ഠിത പരിശോധനകൾക്ക് മുമ്പ് തീരുമാനിക്കാനാകും. ബാക്കിയുള്ള നയത്തിന് യഥാർത്ഥത്തിൽ അതിന്റെ വിലാസം ആവശ്യമുള്ളപ്പോൾ മാത്രം ഒരു പേര് പരിഹരിക്കുക. തുടർന്നുള്ള പല വ്യവസ്ഥകൾക്കും ഒരേ മൂല്യം വേണ്ടെങ്കിൽ ഫലം ഒരു ലോക്കൽ വേരിയബിളിൽ സൂക്ഷിക്കുക.

മുകളിൽ നിരുപാധികമായ DIRECT റിട്ടേൺ ചേർത്ത് സാവധാന സ്ക്രിപ്റ്റ് “ശരിയാക്കരുത്”. അത് കാലതാമസത്തോടൊപ്പം റൂട്ടിംഗ് തീരുമാനവും നീക്കം ചെയ്യുന്നു.

മെഷീൻ-നിർദ്ദിഷ്ട DNS പരിഹാരങ്ങൾക്ക് തെളിവ് വേണം. ഫയൽ പങ്കിടൽ പ്രവർത്തനക്ഷമമാക്കുന്നതോ ഓരോ ലാപ്ടോപ്പിന്റെയും hosts ഫയൽ വീണ്ടും എഴുതുന്നതോ സാവധാന റൂട്ടിംഗ് സ്ക്രിപ്റ്റിനോടുള്ള മോശം ആദ്യ പ്രതികരണമാണ്. ബാധിത നെറ്റ്വർക്കിൽ റിസോൾവറിന്റെയും ഹോസ്റ്റ്നെയിമിന്റെയും സ്വഭാവം പരിശോധിക്കുക, പ്രത്യേകിച്ച് നെറ്റ്വർക്ക് മാറ്റത്തിന് ശേഷം, PAC അതിന്റെ യഥാർത്ഥ തീരുമാന പാത ആവശ്യപ്പെടുന്നിടത്ത് മാത്രം മാറ്റുക.