Squid ບໍ່ສາມາດ bind listener ຂອງຕົນໄດ້: ກວດສອບທີ່ຢູ່ກ່ອນ

ຂໍ້ຜິດພາດ bind ເກີດຂຶ້ນໃນໂຮສ proxy ກ່ອນທີ່ລູກຄ້າຈະສາມາດໃຊ້ listener ທີ່ຕັ້ງໃຈໄດ້. ການປ່ຽນ URL ເວັບໄຊ ຫຼື ລະຫັດຜ່ານ proxy ຈະບໍ່ເຮັດໃຫ້ທີ່ຢູ່ທ້ອງຖິ່ນທີ່ບໍ່ມີຢູ່ນັ້ນພ້ອມໃຊ້.

ອ່ານ endpoint ທີ່ລົ້ມເຫຼວທັງໝົດ: ທີ່ຢູ່, ພອດ ແລະ ຄອບຄົວທີ່ຢູ່. ຂໍ້ຄວາມທີ່ມີ [::1] ກ່ຽວຂ້ອງກັບ IPv6 loopback. ມັນບໍ່ຄືກັນກັບ ການເຊື່ອມຕໍ່ອອກໄປຫາເວັບໄຊ IPv6 ບໍ່ໄດ້.

ຖາມວ່າ namespace ເຄືອຂ່າຍໃດເປັນເຈົ້າຂອງມັນ

ສຳລັບ proxy ໃນ container, ກວດສອບທີ່ຢູ່ທີ່ມີຢູ່ໃນສະພາບແວດລ້ອມເຄືອຂ່າຍຂອງ container. ການສະໜັບສະໜູນ IPv6 ແລະ ການຕັ້ງຄ່າທີ່ຢູ່ອາດແຕກຕ່າງຈາກໂຮສ. ການເຜີຍແຜ່ພອດ container ບໍ່ໄດ້ສ້າງທຸກທີ່ຢູ່ທີ່ບໍລິການພະຍາຍາມ bind ໂດຍອັດຕະໂນມັດ.

ເອກະສານອ້າງອີງ listener ຂອງ Squid ອະທິບາຍວ່າທີ່ຢູ່ຊັດເຈນ bind endpoint ທ້ອງຖິ່ນສະເພາະ. ຊື່ໂຮສອາດເພີ່ມແຫຼ່ງຄວາມສັບສົນອີກ ຖ້າມັນແກ້ໄປຫາທີ່ຢູ່ທີ່ບໍ່ມີໃນສະພາບແວດລ້ອມນັ້ນ.

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

ຖ້າການຕິດຕັ້ງເປັນ IPv4 ຢ່າງຕັ້ງໃຈ, ໃຫ້ເລືອກ listener IPv4 ທີ່ຊັດເຈນເໝາະສົມພາຍໃຕ້ນະໂຍບາຍການເຂົ້າເຖິງທີ່ຕັ້ງໃຈ. ຖ້າຕ້ອງການ IPv6, ໃຫ້ຕັ້ງຄ່າສະພາບແວດລ້ອມນັ້ນໃຫ້ຮອງຮັບມັນ. ການ bind ສາທາລະນະກັບທີ່ຢູ່ wildcard ພຽງເພື່ອໃຫ້ຂໍ້ຜິດພາດງຽບ ອາດເປີດເຜີຍ proxy ກວ້າງກວ່າທີ່ຕັ້ງໃຈ.

ສຸດທ້າຍ, ກວດສອບວ່າ socket ທີ່ລົ້ມເຫຼວແມ່ນ listener HTTP ທີ່ຫັນໜ້າໄປຫາລູກຄ້າ ຫຼື ອົງປະກອບອື່ນຂອງ Squid. ຄຳເຕືອນໜຶ່ງບໍ່ໄດ້ພິສູດວ່າ listener ທັງໝົດລົ້ມເຫຼວ, ແຕ່ socket ທີ່ບໍ່ກ່ຽວຂ້ອງທີ່ເຮັດວຽກໄດ້ ກໍບໍ່ໄດ້ພິສູດວ່າ endpoint ທີ່ລູກຄ້າຕ້ອງການນັ້ນພ້ອມໃຊ້.