ເຊື່ອມຕໍ່ລູກຄ້າ SOCKS ໄປຫາແມ່ HTTP CONNECT ດ້ວຍ 3proxy

ແອັບຯຕ້ອງການ SOCKS. ບໍລິການຕົ້ນທາງທີ່ໄດ້ຮັບອະນຸມັດຂອງທ່ານຮັບ HTTP CONNECT. ການໃສ່ຈຸດປາຍ HTTP ໃນຊ່ອງ SOCKS ຂອງແອັບຯ ບໍ່ໄດ້ແປລະຫວ່າງໂປໂຕຄອນ.

ປະຕູສາມາດຮັບ SOCKS ຈາກແອັບຯ, ອ່ານປາຍທາງທີ່ຮ້ອງຂໍ ແລະ ຂໍຈາກແມ່ HTTP ໃຫ້ເປີດອຸໂມງ CONNECT ໄປຫາປາຍທາງນັ້ນ. ຫຼັງຈາກນັ້ນມັນສົ່ງກະແສຂອງແອັບຯຜ່ານອຸໂມງ.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

ເຮັດໃຫ້ແຕ່ລະອິນເຕີເຟດຊັດເຈນ

ສຳລັບປະຕູທີ່ຮອງຮັບການຈັດວາງນີ້, ປະເພດແມ່ຂອງມັນສຳຄັນ. ເອກະສານ 3proxy ແຍກແມ່ connect ອອກຈາກແມ່ທີ່ໃຊ້ເປັນພຣັອກຊີສົ່ງຕໍ່ HTTP ທຳມະດາ.

ດ້ວຍຜູ້ໃຊ້ 3proxy ແລະ ການພິສູດຢືນຢັນທີ່ມີຢູ່ແລ້ວ, ສ່ວນການເສັ້ນທາງພາຍໃນເຄືອຂ່າຍດຽວສາມາດມີຮູບແບບນີ້:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

ສ່ວນນີ້ສົມມຸດວ່າບັນຊີຖືກກຳນົດໄວ້ແລ້ວ. ມັນບໍ່ເພີ່ມຂໍ້ມູນຢືນຢັນໃດໆທີ່ແມ່ HTTP ເອງຕ້ອງການ ແລະ ບໍ່ແທນນະໂຍບາຍການເຂົ້າເຖິງທີ່ມີຢູ່. ສຳລັບປາຍທາງສາທາລະນະໃນເສັ້ນທາງທີ່ອະນຸຍາດແມ່ HTTP ສາທາລະນະທີ່ບໍ່ມີການພິສູດຢືນຢັນ, ລາຍການພຣັອກຊີ HTTP ສະເໜີຜູ້ສະໝັກເປັນໂຮສ ແລະ ພອດ. ໃຫ້ຂໍ້ມູນຢືນຢັນຂອງແມ່ຂາດຢູ່ສຳລັບສາຂານັ້ນ ແລະ ຢືນຢັນການອະນຸຍາດສຳລັບເປົ້າໝາຍຕົວຈິງ; ບັນຊີຂອງປະຕູເອງຍັງເປັນພາຍໃນເຄືອຂ່າຍ. ກົດ parent ເຊື່ອມໂຍງກັບກົດ allow ກ່ອນໜ້ານີ້ຕາມແບບການຕັ້ງຄ່າທີ່ເອກະສານ 3proxy ກຳນົດໄວ້.

ແອັບຯໃຊ້ຈຸດປາຍ SOCKS ພາຍໃນ. ປະຕູໃຊ້ HTTP CONNECT ໄປຫາແມ່. ແມ່ຍັງເປັນຜູ້ຕັດສິນວ່າໂຮສ ແລະ ພອດປາຍທາງທີ່ຮ້ອງຂໍນັ້ນອະນຸຍາດຫຼືບໍ່.

ຂອບເຂດທີ່ເປັນປະໂຫຍດໃນທີ່ນີ້ແມ່ນການເຮັດອຸໂມງກະແສ TCP ທຳມະດາ. ສະມາຄົມ UDP ຂອງ SOCKS5 ບໍ່ໄດ້ກາຍເປັນທີ່ຮອງຮັບພຽງເພາະຜູ້ຟັງດ້ານໜ້າຮັບ SOCKS5. ແມ່ HTTP CONNECT ບໍ່ໄດ້ໃຫ້ relay UDP ທີ່ຕ້ອງການໂດຍອັດຕະໂນມັດ.

HTTPS ສາມາດຢູ່ແບບປາຍຕໍ່ປາຍໄດ້ໃນເສັ້ນທາງນີ້; ການແປລະຫວ່າງອິນເຕີເຟດພຣັອກຊີບໍ່ຕ້ອງການປອມຕົວເປັນເວັບໄຊປາຍທາງ. ການພິສູດຢືນຢັນຕໍ່ປະຕູ, ຕໍ່ແມ່ ແລະ ຕໍ່ເວັບໄຊ ຍັງເປັນຂໍ້ມູນ ແລະ ການແລກປ່ຽນທີ່ແຕກຕ່າງກັນ.