AllowCONNECT ຂອງ Apache ແລະພອດປາຍທາງ HTTPS

ພຣັອກຊີ Apache ຂອງທ່ານຟັງຢູ່ພອດ 3128. ລູກຄ້າສາມາດໄປຮອດໄດ້ຢ່າງສຳເລັດ ແຕ່ບໍລິການ HTTPS ຢູ່ພອດ 8443 ລົ້ມເຫລວ. ການປ່ຽນພອດຟັງຂອງພຣັອກຊີອາດບໍ່ແກ້ໄຂຄວາມແຕກຕ່າງສະເພາະນັ້ນ.

ລູກຄ້າເຊື່ອມຕໍ່ກັບຜູ້ຟັງຂອງພຣັອກຊີກ່ອນ. ຈາກນັ້ນ ຄຳຮ້ອງ CONNECT ຂອງມັນຈະລະບຸໂຮສ ແລະ ພອດປາຍທາງແຍກຕ່າງຫາກ. Apache ສາມາດຮັບການເຊື່ອມຕໍ່ທຳອິດ ແລະ ປະຕິເສດການດຳເນີນການທີສອງ.

ອ່ານ AllowCONNECT ເປັນນະໂຍບາຍປາຍທາງ

ສຳລັບ Apache 2.4, mod_proxy_connect ຈັດການຄຳຮ້ອງ CONNECT ທີ່ເຂົ້າມາ. ຄຳສັ່ງ AllowCONNECT ຂອງມັນຄວບຄຸມພອດປາຍທາງທີ່ມີໃຫ້ສຳລັບຄຳຮ້ອງເຫຼົ່ານັ້ນ. ຄ່າເລີ່ມຕົ້ນທີ່ລະບຸໄວ້ແມ່ນ 443 ແລະ 563.

AllowCONNECT 443 8443

ຕົວຢ່າງນີ້ເລືອກສອງພອດປາຍທາງນັ້ນ. ມັນແທນການເລືອກເລີ່ມຕົ້ນ; ມັນບໍ່ໄດ້ເພີ່ມ 8443 ໃນຂະນະທີ່ຮັກສາທຸກພອດເລີ່ມຕົ້ນໄວ້ຢ່າງງຽບໆ. ໃຊ້ຄຳສັ່ງໃນການຕັ້ງຄ່າເຊີບເວີ ຫຼື ໂຮສສະເໝືອນທີ່ກ່ຽວຂ້ອງ.

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

ຕົວຢ່າງພຣັອກຊີຍ້ອນກັບຕອບຄຳຖາມອື່ນ

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

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