JDK 25 HttpClient لا يستخدم مسارات SOCKS من ProxySelector

يصف كائن الوكيل في جافا مسارًا. ولا يزال عميل الشبكة هو الذي يقرر أنواع المسارات التي يمكنه استخدامها. وهذا مهم عندما تتحدث نقطة النهاية المتاحة بروتوكول SOCKS ويستخدم التطبيق java.net.http.HttpClient.

في تنفيذ JDK 25 الذي نفحصه هنا، يقبل رمز الطلب في عميل HTTP مرشحًا من نوع HTTP من المحدِّد. أما مرشح SOCKS فلا يجعله يجري تفاوض SOCKS؛ ويمكن للتنفيذ أن يستمر دون وكيل. لذا فإن الاستجابة الناجحة ليست دليلًا كافيًا على أن إدخال SOCKS في محدِّد مخصص قد استُخدم.

اختر النقل أولًا

في تطبيق قائم على URLConnection، يمكن إعطاء معالج البروتوكول وكيلًا صريحًا مدعومًا عند فتح الاتصال:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

لاختبارات الأهداف العامة المسموح بها، استخدم نقطة نهاية SOCKS مطابقة من خدمتك أو من قائمة وكلاء SOCKS. هذه واجهة برمجة عميل مختلفة، وليست كتابة بديلة لـ HttpClient.Builder.proxy. حافظ على عنوان URL الوجهة كي يظل HTTPS يحدد الموقع المقصود.

أما التطبيق الذي يجب أن يحتفظ بـ java.net.http فيمكنه بدلًا من ذلك استخدام نقطة نهاية وكيل HTTP متوافقة، بما في ذلك محوِّل معتمد يتولى اتصال SOCKS اللاحق. وهذا يضيف مكوّنًا حقيقيًا وحدًا آخر للوصول؛ وتغيير المنفذ 8080 إلى 1080 لا يوفّر هذا التحويل.

اجعل الاختيار والتبنّي مرئيين

سجّل نتيجة المحدِّد والاتصال الذي يفتحه العميل فعلًا معًا. الأول يصف مخرجات السياسة؛ والثاني يثبت ما إذا كان التنفيذ قد تبنّاها.

اربط الاستنتاجات ببيئة التشغيل والنقل المستخدمين. فخصائص SOCKS في JVM التي يستخدمها تنفيذ مقبس واحد ليست وعدًا بأن كل مكتبة HTTP ترجع إليها. وعندما يكون المسار إلزاميًا، ينبغي كشف نوع الوكيل غير المدعوم قبل قبول طلب مباشر يبدو ناجحًا.