JDK 25 HttpClient ບໍ່ໄດ້ໃຊ້ເສັ້ນທາງ SOCKS ຂອງ ProxySelector

ວັດຖຸ proxy ຂອງ Java ອະທິບາຍເສັ້ນທາງໜຶ່ງ. ລູກຄ້າເຄືອຂ່າຍຍັງເປັນຜູ້ຕັດສິນວ່າຈະໃຊ້ເສັ້ນທາງປະເພດໃດໄດ້. ສິ່ງນີ້ສຳຄັນເມື່ອຈຸດສຸດທ້າຍທີ່ມີຢູ່ເວົ້າ SOCKS ແລະ ແອັບໃຊ້ java.net.http.HttpClient.

ໃນການຈັດຕັ້ງ JDK 25 ທີ່ກວດສອບຢູ່ນີ້, ລະຫັດຄຳຮ້ອງຂອງລູກຄ້າ HTTP ຮັບຜູ້ສະໝັກ HTTP ຈາກຕົວເລືອກ. ຜູ້ສະໝັກ SOCKS ບໍ່ເຮັດໃຫ້ມັນດຳເນີນການເຈລະຈາ SOCKS; ການຈັດຕັ້ງສາມາດສືບຕໍ່ໂດຍບໍ່ມີ proxy. ດັ່ງນັ້ນການຕອບສະໜອງທີ່ສຳເລັດບໍ່ແມ່ນຫຼັກຖານພຽງພໍວ່າລາຍການ SOCKS ຂອງຕົວເລືອກແບບກຳນົດເອງຖືກໃຊ້.

ເລືອກການຂົນສົ່ງກ່ອນ

ສຳລັບແອັບຯທີ່ມີຢູ່ແລ້ວໂດຍອີງໃສ່ URLConnection, ຕົວຈັດການໂປຣໂຕຄໍສາມາດໄດ້ຮັບ proxy ທີ່ຮອງຮັບຢ່າງຊັດເຈນເມື່ອເປີດການເຊື່ອມຕໍ່:

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 ທີ່ກົງກັນຈາກບໍລິການຂອງທ່ານ ຫຼື ຈາກລາຍຊື່ proxy SOCKS. ນີ້ແມ່ນ API ລູກຄ້າອື່ນ, ບໍ່ແມ່ນການສະກົດຄຳສຳຮອງຂອງ HttpClient.Builder.proxy. ຮັກສາ URL ປາຍທາງໄວ້ ເພື່ອໃຫ້ HTTPS ສືບຕໍ່ລະບຸເວັບໄຊທີ່ຕັ້ງໃຈ.

ແອັບຯທີ່ຕ້ອງຮັກສາ java.net.http ສາມາດໃຊ້ຈຸດສຸດທ້າຍ proxy HTTP ທີ່ເຂົ້າກັນໄດ້ແທນ, ລວມທັງອະແດັບເຕີທີ່ໄດ້ຮັບອະນຸມັດທີ່ຈັດການການເຊື່ອມຕໍ່ SOCKS ຕໍ່ໄປ. ນັ້ນເພີ່ມອົງປະກອບທີ່ແທ້ຈິງ ແລະ ຂອບເຂດການເຂົ້າເຖິງອີກອັນໜຶ່ງ; ການປ່ຽນພອດ 8080 ເປັນ 1080 ບໍ່ໄດ້ໃຫ້ການແປນັ້ນ.

ເຮັດໃຫ້ການເລືອກ ແລະ ການຮັບເອົາເຫັນໄດ້

ບັນທຶກທັງຜົນຂອງຕົວເລືອກ ແລະ ການເຊື່ອມຕໍ່ທີ່ລູກຄ້າເປີດຕົວຈິງ. ອັນທຳອິດອະທິບາຍຜົນຂອງນະໂຍບາຍ; ອັນທີສອງກຳນົດວ່າການຈັດຕັ້ງໄດ້ຮັບເອົາຫຼືບໍ່.

ຜູກຂໍ້ສະຫຼຸບໄວ້ກັບ runtime ແລະ ການຂົນສົ່ງທີ່ໃຊ້. ຄຸນສົມບັດ SOCKS ຂອງ JVM ທີ່ການຈັດຕັ້ງ socket ໜຶ່ງໃຊ້ ບໍ່ແມ່ນຄຳສັນຍາວ່າທຸກຫ້ອງສະໝຸດ HTTP ຈະສອບຖາມພວກມັນ. ເມື່ອເສັ້ນທາງເປັນຂໍ້ບັງຄັບ, ຄວນກວດພົບປະເພດ proxy ທີ່ບໍ່ຮອງຮັບ ກ່ອນທີ່ຈະຮັບຄຳຮ້ອງໂດຍກົງທີ່ເບິ່ງຄືວ່າສຳເລັດ.