ຂໍ້ຄວາມສະຖານະກ່າວວ່າ “Resolving host in proxy script,” ແຕ່ການປ່ຽນເຊີບເວີພຣັອກຊີບໍ່ຄ່ອຍປ່ຽນຫຍັງ. ນີ້ເປັນຂໍ້ບົ່ງຊີ້ທີ່ເປັນປະໂຫຍດ: ບຣາວເຊີອາດຈະຍັງຕັດສິນໃຈວ່າຈະສົ່ງຄຳຮ້ອງຂໍໄປໃສ.

ໄຟລ໌ PAC ສາມາດເຮັດການກວດສອບທີ່ຂຶ້ນກັບ DNS. ຖ້າການກວດສອບເຫຼົ່ານັ້ນລໍຖ້າ resolver ທີ່ເຂົ້າເຖິງບໍ່ໄດ້ ຫຼື ຖາມຄຳຖາມທີ່ບໍ່ຈຳເປັນຊ້ຳແລ້ວຊ້ຳອີກ, ການໂຫຼດໜ້າເວັບອາດຈະຢຸດກ່ອນທີ່ພຣັອກຊີທີ່ເລືອກຈະໄດ້ຮັບຫຍັງ.

1. ຊອກຫາຈຸດທີ່ຢຸດ

ສຳລັບ URL ໜຶ່ງທີ່ໄດ້ຮັບຜົນກະທົບ, ກຳນົດວ່າຄວາມຊ້າເກີດຂຶ້ນຕອນດຶງໄຟລ໌ PAC, ຕອນປະເມີນມັນ ຫຼື ຕອນເຊື່ອມຕໍ່ກັບພຣັອກຊີທີ່ສົ່ງກັບມາ. ບັນທຶກການເຂົ້າເຖິງຂອງພຣັອກຊີທີ່ຫວ່າງເປົ່າສອດຄ່ອງກັບສອງຂັ້ນຕອນທຳອິດ; ມັນບໍ່ໄດ້ພິສູດວ່າບຣາວເຊີໃຊ້ເສັ້ນທາງກົງ.

ຈາກນັ້ນກວດເບິ່ງວ່າກົດເກນໃດຕ້ອງການ DNS. ຄຳແນະນຳກ່ຽວກັບປະສິດທິພາບ PAC ຂອງ Microsoft ແນະນຳໃຫ້ຫຼີກລ້ຽງວຽກທີ່ຂຶ້ນກັບ DNS ທີ່ບໍ່ຈຳເປັນ. ການກວດຄວາມເທົ່າກັນຂອງຊື່ໂຮສບໍ່ຕ້ອງການຂໍ້ມູນດຽວກັນກັບການແກ້ຊື່ໂຮສນັ້ນ ແລະ ການກວດຊັບເນັດ.

2. ລຶບວຽກ DNS ທີ່ບໍ່ຈຳເປັນ

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

ຢ່າ “ແກ້ໄຂ” ສະຄຣິບທີ່ຊ້າໂດຍການເພີ່ມການສົ່ງຄືນ DIRECT ແບບບໍ່ມີເງື່ອນໄຂຢູ່ເທິງ. ມັນລຶບການຕັດສິນເລື່ອງເສັ້ນທາງພ້ອມກັບຄວາມຊ້າ.

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

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