Windows को ProxyServer मान नक्सा हुन सक्छ

पूरै मान एकल URI कन्स्ट्रक्टरमा नदिई प्रोटोकल-विशेष Windows प्रोक्सी स्ट्रिङहरू पहिचान गर्नुहोस्।

एउटा स्क्रिप्टले Windows Internet Settings बाट ProxyServer पढ्छ र यसलाई WebProxy.Address मा तोक्छ। यो एउटा मेसिनमा काम गर्छ, त्यसपछि अर्को मेसिनमा असफल हुन्छ जसको मान यस्तो देखिन्छ:

http=proxy-a.example:8080;https=proxy-b.example:8080

यो प्रोटोकल-विशेष कन्फिगरेसन स्ट्रिङ हो, एकल प्रोक्सी URI होइन। एकल ठेगाना अपेक्षा गर्ने कन्स्ट्रक्टरमा पूरै मान दिँदा इनपुटको अर्थ बदलिन्छ।

प्रविष्टियसका लागि प्रोक्सी छान्छ
http=...HTTP गन्तव्य अनुरोधहरू
https=...HTTPS गन्तव्य अनुरोधहरू

https कुञ्जी आफैले त्यो प्रोक्सीसँगको जडानले TLS प्रयोग गर्छ भन्ने अर्थ दिँदैन। साधारण HTTP प्रोक्सीले CONNECT मार्फत HTTPS गन्तव्य बोक्न सक्छ।

क्लाइन्टले उपलब्ध गराएको ठाउँमा वास्तविक गन्तव्यका लागि समर्थित प्रणाली-प्रोक्सी इन्टरफेसलाई प्राथमिकता दिनुहोस्। म्यानुअल प्रोक्सी स्ट्रिङ, बाइपास नियम, स्वचालित कन्फिगरेसन URL र स्वचालित पत्ता लगाउने कन्फिगरेसनका फरक भागहरू हुन्। एउटा रजिस्ट्री मान पढेर ती सबै पुनः उत्पादन गर्न सकिँदैन। यदि तपाईंले भण्डारण गरिएको नक्सा जाँच्नुभयो भने, ProxyServer को छेउमा ProxyEnable र AutoConfigURL पढ्नुहोस्.

यदि कुनै एकीकरणले म्यानुअल म्यापिङ पार्स गर्नुपर्छ भने, यसको कागजात गरिएको ढाँचा पालना गर्नुहोस्, प्रोटोकल सम्बन्ध कायम राख्नुहोस् र प्रत्येक छानिएको मानका लागि वास्तविक URI वा एन्डपोइन्ट पार्सर प्रयोग गर्नुहोस्। प्रत्येक कोलन विभाजन गर्दा IPv6 बिग्रन्छ; पहिलो प्रविष्टि छान्दा माथिको भिन्नता हराउँछ।

यसलाई उपयुक्त खाता सन्दर्भभित्र राख्नुहोस्। अन्तरक्रियात्मक प्रयोगकर्ताको सेटिङहरू अर्को पहिचानअन्तर्गत चल्ने सेवाको सेटिङहरू स्वचालित रूपमा होइनन्।

सम्बन्धित लेखहरू