Java نے آپ کی HTTP درخواست کے لیے SOCKS پراکسی کیوں منتخب کی

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 امیدوار کو بلا تفریق فلٹر کرنا ایسے کنکشن توڑ سکتا ہے جنہیں اسے استعمال کرنا تھا۔ غلط قاعدے کو اُس کم سے کم دائرہ کار کے ساتھ درست کریں جو آپ شناخت کر سکیں۔