Java ने आपके HTTP अनुरोध के लिए SOCKS प्रॉक्सी क्यों चुना
पुराने Windows प्रॉक्सी उपाय लागू करने से पहले ProxySelector परिणाम और प्रभावी JVM सेटिंग्स जाँचें।
एक Java अनुरोध कई प्रॉक्सी इनपुट से मिल सकता है: स्पष्ट क्लाइंट कॉन्फ़िगरेशन, डिफ़ॉल्ट सेलेक्टर, JVM नेटवर्किंग प्रॉपर्टीज़ और समर्थित ऑपरेटिंग-सिस्टम सेटिंग्स। जब कोई लॉग अप्रत्याशित रूप से SOCKS का उल्लेख करे, तो पहचानें कि किस इनपुट ने इसे चुना।
डिफ़ॉल्ट सेलेक्टर का उपयोग करने वाले कोड के लिए, ठीक उसी गंतव्य के लिए निर्णय जाँचें:
URI target = URI.create("https://example.com/");
ProxySelector selector = ProxySelector.getDefault();
if (selector != null) {
System.out.println(selector.select(target));
}
यह सेलेक्टर के उम्मीदवारों की जानकारी देता है। यह सिद्ध नहीं करता कि अंततः कौन-सा कनेक्शन सफल हुआ, और अपना स्पष्ट मार्ग रखने वाला क्लाइंट अलग चुनाव कर सकता है।
प्रभावी सेटिंग्स जाँचें
http.proxyHost, https.proxyHost, socksProxyHost, उनके पोर्ट और java.net.useSystemProxies की समीक्षा करें। JDK नेटवर्किंग-प्रॉपर्टी दस्तावेज़ उनका दायरा और प्राथमिकता बताता है। सिस्टम प्रॉक्सी खोज स्टार्टअप पर जाँची जाती है; JVM शुरू करते समय इसे जानबूझकर सेट करें।
ऐतिहासिक उत्तर पुराने Windows संवादों और पुराने JDK के विशिष्ट संयोजनों का वर्णन करते हैं। वे रिपोर्टें किसी उपाय के मूल को समझा सकती हैं, पर यह सिद्ध नहीं करतीं कि किसी वर्तमान रनटाइम में वही बग है। हर एप्लिकेशन के लिए ऑपरेटिंग-सिस्टम सेटिंग्स बदलने से पहले रनटाइम संस्करण और सेलेक्टर का आउटपुट दर्ज करें।
यदि एप्लिकेशन को एक क्लाइंट के लिए HTTP प्रॉक्सी चाहिए, तो एक स्पष्ट प्रॉक्सी कॉन्फ़िगरेशन उस आवश्यकता को स्पष्ट कर सकता है। यदि उसे केंद्रीय स्वचालित राउटिंग चाहिए, तो जाँचें कि सेलेक्टर को अप्रत्याशित SOCKS प्रविष्टि क्यों मिली या क्यों लौटाई गई।
कस्टम सेलेक्टर को जानबूझकर किए गए बायपास और विफलता-प्रबंधन को बनाए रखना चाहिए। हर SOCKS उम्मीदवार को बिना भेदभाव फ़िल्टर करना उन कनेक्शनों को तोड़ सकता है जिन्हें एक का उपयोग करना था। गलत नियम को उस सबसे छोटे दायरे के साथ ठीक करें जिसे आप पहचान सकें।