Proxychains ຜ່ານ Squid: ຂໍ້ຈຳກັດ CONNECT ເທິງພອດ 80

ບຣາວເຊີໂຫລດໜ້າ HTTP ຜ່ານ Squid. ປາຍທາງດຽວກັນນັ້ນລົ້ມເຫຼວພາຍໃຕ້ proxychains. ນັ້ນບໍ່ໄດ້ໝາຍຄວາມວ່າໂປຣແກຣມໃດໜຶ່ງໃນສອງໄດ້ເລືອກ IP ພຣັອກຊີຜິດ.

ໄຄເອັນ HTTP ທຳມະດາສາມາດສົ່ງຄຳຮ້ອງເວັບໄປຫາພຣັອກຊີທາງໜ້າໃນຮູບແບບ HTTP proxy. ແຕ່ຕົວຫຸ້ມ socket ທົ່ວໄປຕ້ອງການ ອຸໂມງໄບຕ໌ ສຳລັບການເຊື່ອມຕໍ່ທີ່ແອັບຯຕ້ອງການເປີດ. ສຳລັບ HTTP proxy ໃນລະບົບໂສ້ຂອງມັນ proxychains ໃຊ້ CONNECT.

ໝາຍຄວາມວ່າເວັບໄຊທີ່ເປັນຂໍ້ຄວາມທຳມະດາເທິງພອດ 80 ສາມາດສ້າງຄຳຮ້ອງ CONNECT ສຳລັບພອດ 80. ນະໂຍບາຍ Squid ທີ່ອະນຸຍາດ CONNECT ສະເພາະລາຍຊື່ພອດ TLS ທີ່ອະນຸມັດສາມາດປະຕິເສດອຸໂມງນັ້ນ ເຖິງແມ່ນຄຳຮ້ອງ HTTP ທຳມະດາໄປພອດ 80 ໄດ້ຮັບອະນຸຍາດ.

ປຽບທຽບຄຳຮ້ອງ ບໍ່ແມ່ນພຽງຊື່ໂຮສ

ເອກະສານ proxychains-ng ອະທິບາຍການສະໜັບສະໜູນ HTTP CONNECT ຂອງມັນ. ກົດລະບຽບການເຂົ້າເຖິງຂອງ Squid ສາມາດແຍກວິທີການ ແລະ ພອດປາຍທາງ. ນີ້ແມ່ນເສັ້ນທາງຄຳຮ້ອງຕ່າງກັນໄປຫາເວັບໄຊດຽວກັນ.

ອ່ານເຫດຜົນການປະຕິເສດ ແລະ ນະໂຍບາຍທີ່ຕັ້ງໃຈໄວ້ກ່ອນຈະປ່ຽນມັນ. ການຂະຫຍາຍການເຂົ້າເຖິງ CONNECT ໄປທຸກພອດເປັນການປ່ຽນແປງທີ່ສຳຄັນ; ມັນບໍ່ຄວນເປັນການຕອບສະໜອງເລີ່ມຕົ້ນຕໍ່ຄວາມບໍ່ສອດຄ່ອງຂອງຕົວຫຸ້ມ.

ຖ້າແອັບຯມີການສະໜັບສະໜູນ HTTP proxy ແບບພາຍໃນຕົວ ການໃຊ້ມັນສາມາດຫຼີກລ່ຽງອຸໂມງທົ່ວໄປທີ່ບໍ່ຈຳເປັນສຳລັບ HTTP ຂໍ້ຄວາມທຳມະດາ. ຖ້າມັນຕ້ອງການອຸໂມງ TCP ດິບໆຈິງໆ ໃຫ້ເລືອກໂປຣໂຕຄອນພຣັອກຊີ ແລະ ນະໂຍບາຍພອດທີ່ໄດ້ອະນຸມັດທີ່ໃຫ້ບໍລິການດັ່ງກ່າວ.

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