لماذا اختار Java وكيل SOCKS لطلب HTTP الخاص بك

قد يواجه طلب 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 دون تمييز قد تقطع اتصالات كان يفترض أن تستخدم أحدها. أصلح القاعدة الخاطئة بأصغر نطاق يمكنك تحديده.