কেন 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 প্রার্থীকে নির্বিচারে ফিল্টার করলে যে সংযোগগুলো একটি ব্যবহার করার কথা ছিল সেগুলো ভেঙে যেতে পারে। আপনি শনাক্ত করতে পারেন এমন ক্ষুদ্রতম পরিধিতে ভুল নিয়মটি ঠিক করুন।