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 રૂપરેખાંકન બદલે છે અને તેને સામાન્ય બ્રાઉઝર સમારકામ તરીકે વાપરવો ન જોઈએ. પહેલાનું રૂપરેખાંકન નોંધો અને આ ફેરફાર કરતા પહેલા ખાતરી કરો કે લક્ષ્ય એપ્લિકેશન ખરેખર તેનો ઉપયોગ કરે છે.

વાઇલ્ડકાર્ડ નિયમ અને local ટોકન અલગ કામો કરે છે. 192.168.1.10 જેવું ડોટવાળું IP લિટરલ ડોટ વગરનું હોસ્ટનામ નથી. જો આવું સરનામું સીધું જવું જોઈએ, તો યોગ્ય રીતે સમર્થિત સ્પષ્ટ અપવાદ વાપરો, એમ ધારવાને બદલે કે local શબ્દ તેને આવરી લે છે.

વિનંતીનું વાસ્તવિક હોસ્ટ તપાસો

એક સેવા ટૂંકું નામ વાપરી શકે છે જ્યારે બ્રાઉઝર બુકમાર્ક સંપૂર્ણ યોગ્ય નામ વાપરે છે. પરિણામી માર્ગ અલગ હોઈ શકે છે, પછી ભલે બંને નામ આખરે એક જ સર્વર ઓળખાવે.

વિનંતી એપ્લિકેશન-વિશિષ્ટ પ્રોક્સી માહિતી કે PAC મૂલ્યાંકન દ્વારા પણ સંચાલિત થઈ શકે છે, તમે તપાસેલા સ્થિર ડિફોલ્ટને બદલે. બીજે બાયપાસ યાદી બદલતા પહેલા નિષ્ફળ જતી એપ્લિકેશન કયો સ્રોત વાપરે છે તે ઓળખો.

વર્તન સરખાવવા માટે, એક જ ક્લાયન્ટ માટે URL હોસ્ટનામ અને પસંદ કરેલી પ્રોક્સી નીતિ નોંધો. ફક્ત એટલા માટે કાર્યક્ષમ જાહેર પ્રોક્સી બદલો નહીં કે જાણી જોઈને બાકાત કરેલો હોસ્ટ સીધો જ રહે છે.

આ ભેદને DNS અને કર્નલ રૂટિંગથી અલગ રાખો: બાયપાસ નિયમ પસંદ કરે છે કે વિનંતી માટે પ્રોક્સી વાપરવો કે નહીં. તે અન્યથા પહોંચી ન શકાય તેવા લક્ષ્યને પહોંચી શકાય તેવું બનાવતું નથી.

સંબંધિત લેખો