JDK 25 HttpClient ไม่ได้ใช้เส้นทาง SOCKS ของ ProxySelector

ออบเจ็กต์พร็อกซีของ Java อธิบายเส้นทางหนึ่ง เครือข่ายไคลเอนต์ยังคงเป็นผู้ตัดสินว่าจะใช้เส้นทางชนิดใดได้ สิ่งนี้สำคัญเมื่อปลายทางที่มีอยู่พูด 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 นี่คือ API ของไคลเอนต์ที่แตกต่างกัน ไม่ใช่การสะกดแบบอื่นของ HttpClient.Builder.proxy โปรดเก็บ URL ปลายทางไว้เพื่อให้ HTTPS ยังคงระบุเว็บไซต์ที่ตั้งใจไว้

แอปพลิเคชันที่ต้องคง java.net.http ไว้สามารถใช้ปลายทางพร็อกซี HTTP ที่เข้ากันได้แทน รวมถึงอะแดปเตอร์ที่ได้รับอนุมัติซึ่งจัดการการเชื่อมต่อ SOCKS ต่อไป สิ่งนี้เพิ่มองค์ประกอบจริงและขอบเขตการเข้าถึงอีกชั้น การเปลี่ยนพอร์ต 8080 เป็น 1080 ไม่ได้ให้การแปลนั้น

ทำให้การเลือกและการนำไปใช้มองเห็นได้

บันทึกทั้งผลลัพธ์ของตัวเลือกและการเชื่อมต่อที่ไคลเอนต์เปิดจริง อย่างแรกอธิบายเอาต์พุตของนโยบาย อย่างที่สองระบุว่าการใช้งานนำไปใช้หรือไม่

ผูกข้อสรุปกับรันไทม์และการขนส่งที่ใช้ คุณสมบัติ JVM SOCKS ที่การใช้งานซ็อกเก็ตหนึ่งใช้ไม่ได้เป็นการรับประกันว่าทุกไลบรารี HTTP จะสอบถามคุณสมบัติเหล่านั้น เมื่อเส้นทางเป็นข้อบังคับ ควรตรวจพบชนิดพร็อกซีที่ไม่รองรับก่อนยอมรับคำขอโดยตรงที่ดูเหมือนสำเร็จ