ກົດ portproxy ຂອງ Windows ສົ່ງຕໍ່ TCP ໄປຫາປາຍທາງທີ່ຕັ້ງຄ່າໄວ້ໜຶ່ງແຫ່ງ. ມັນບໍ່ເຈລະຈາກ່ຽວກັບຄຳຮ້ອງ proxy HTTP ຂອງບຣາວເຊີ ຫຼື ຄຳຮ້ອງປາຍທາງ SOCKS.

ບໍລິການໃຜເປັນຜູ້ເລືອກປາຍທາງ?
ຕົວສົ່ງຕໍ່ TCP ຄົງທີ່ການຕັ້ງຄ່າສົ່ງຕໍ່ຂອງຜູ້ຟັງ.
proxy SOCKS5ຄຳຮ້ອງຂອງລູກຄ້າ, ພາຍໃນນະໂຍບາຍຂອງເຊີບເວີ.
proxy HTTP ສົ່ງຕໍ່ຄຳຮ້ອງ proxy HTTP, ລວມທັງ CONNECT ສຳລັບອຸໂມງ HTTPS ທົ່ວໄປ.

ກວດເບິ່ງຕົວສົ່ງຕໍ່ທີ່ມີຢູ່ດ້ວຍ netsh interface portproxy show all. ປຽບທຽບ backend ທີ່ຕັ້ງຄ່າໄວ້ກັບໂປຣໂຕຄອນທີ່ລູກຄ້າຂອງທ່ານສົ່ງໄປ. ເອກະສານອ້າງອີງ netsh ອະທິບາຍທີ່ຢູ່/ພອດຂອງຜູ້ຟັງ ແລະ ປາຍທາງ; ການຮັບ TCP ບໍ່ໄດ້ສ້າງການຈັບມື HTTP ຫຼື SOCKS.

ການເຈລະຈາ SOCKS ທີ່ສົ່ງໄປຫາຕົວສົ່ງຕໍ່ທຳມະດາ ພຽງແຕ່ໄປຮອດ backend ຄົງທີ່ນັ້ນ. ມັນບໍ່ສາມາດເຮັດໃຫ້ບໍລິການທີ່ບໍ່ແມ່ນ SOCKS ເຂົ້າໃຈຄຳຮ້ອງ ຫຼື ເລືອກເປົ້າໝາຍໃໝ່ໄດ້.

ຕົວສົ່ງຕໍ່ທີ່ຢູ່ໜ້າ proxy ແທ້ແມ່ນແຕກຕ່າງ. proxy ທາງເທິງຍັງເຈລະຈາປາຍທາງ ແລະ ການພິສູດຕົວຕົນ; ຕົວສົ່ງຕໍ່ພາການເຊື່ອມຕໍ່ໄປຫາມັນ. ຕົວສົ່ງຕໍ່ທີ່ເປີດສູ່ເຄືອຂ່າຍສາມາດຂະຫຍາຍການເຂົ້າເຖິງ backend ນັ້ນ, ດັ່ງນັ້ນຈົ່ງຮັກສາ ຂອບເຂດການເຂົ້າເຖິງຂອງຜູ້ຟັງ ໄວ້ຢ່າງຕັ້ງໃຈ.

ເລືອກບໍລິການທີ່ຮອງຮັບໂປຣໂຕຄອນ ເມື່ອຄວາມຕ້ອງການແມ່ນທາງອອກ HTTP ຫຼື SOCKS ທົ່ວໄປ. ພອດທີ່ສົ່ງຕໍ່ເປັນພຽງສ່ວນໜຶ່ງຂອງເສັ້ນທາງນັ້ນ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ