WinHTTP च्या बायपास यादीत <local> हे विशेष टोकन असू शकते. या संदर्भात local म्हणजे बिंदू नसलेले सर्व्हर नाव. हे प्रत्येक खाजगी IP पत्त्याचे किंवा तुमच्या Wi-Fi वरील प्रत्येक उपकरणाचे सामान्य वर्गीकरण नाही.

त्यामुळे लहान होस्टनाव आणि बिंदू असलेले होस्टनाव वेगळे इनपुट ठरतात. http://intranet/ मागणारे अनुप्रयोग टोकनशी जुळू शकते, तर http://intranet.example.internal/ ला लागू स्पष्ट नियम आवश्यक असतो.

संरचित अपवाद वाचा

इच्छित WinHTTP संरचनेसाठी एक स्थिर उदाहरण असे आहे:

netsh winhttp set proxy `
  proxy-server="203.0.113.10:8080" `
  bypass-list="<local>;*.example.internal"

एंडपॉइंट फक्त उदाहरणासाठी आहे. हा आदेश WinHTTP संरचना बदलतो आणि सामान्य ब्राउझर दुरुस्ती म्हणून वापरू नये. बदल करण्यापूर्वी पूर्वीची संरचना नोंदवा आणि लक्ष्य अनुप्रयोग ती खरोखर वापरतो याची पुष्टी करा.

वाइल्डकार्ड नियम आणि स्थानिक टोकन वेगवेगळी कामे करतात. 192.168.1.10 सारखे बिंदू असलेले IP लिटरल हे बिंदू नसलेले होस्टनाव नाही. अशा पत्त्याने थेट जायचे असेल तर local हा शब्द त्याला समावतो असे गृहीत धरण्याऐवजी योग्यरीत्या समर्थित स्पष्ट अपवाद वापरा.

विनंतीचा प्रत्यक्ष होस्ट तपासा

सेवा लहान नाव वापरू शकते, तर ब्राउझर बुकमार्क पूर्णपणे पात्र नाव वापरतो. दोन्ही नावे शेवटी एकाच सर्व्हरकडे निर्देश करत असली तरी परिणामी मार्ग वेगळा असू शकतो.

विनंती तुम्ही तपासलेल्या स्थिर डीफॉल्टऐवजी अनुप्रयोग-विशिष्ट प्रॉक्सी माहिती किंवा PAC मूल्यमापनानेही नियंत्रित होऊ शकते. इतरत्र बायपास यादी बदलण्यापूर्वी अयशस्वी होणारा अनुप्रयोग वापरत असलेला स्रोत ओळखा.

वर्तनाची तुलना करण्यासाठी, URL मधील होस्टनाव आणि त्याच क्लायंटसाठी निवडलेले प्रॉक्सी धोरण नोंदवा. जाणीवपूर्वक वगळलेला होस्ट थेट राहतो म्हणून कार्यरत सार्वजनिक प्रॉक्सी बदलू नका.

हा फरक DNS आणि कर्नल राउटिंगपासून वेगळा ठेवा: बायपास नियम विनंतीसाठी प्रॉक्सी वापरायचा की नाही हे निवडतो. तो अन्यथा न पोहोचणारे गंतव्य पोहोचण्यायोग्य करत नाही.

संबंधित लेख