WORDPRESS网站500、502、503、504错误的4大罪魁祸首

ຂ້ອຍໃຊ້ ເວັບໄຊທ໌ WordPress ຫຼາຍແຫ່ງ , ແລະຄັ້ງໜຶ່ງຂ້ອຍເຄີຍສູນເສຍການເຂົ້າຊົມຫຼາຍກວ່າ 800 ຄັ້ງໃນມື້ດຽວຍ້ອນຄວາມຜິດພາດ 502. ຫຼັງຈາກສືບສວນເປັນເວລາສາມມື້, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າຕົວການນັ້ນຢູ່ໃນສະພາບແວດລ້ອມທີ່ບໍ່ຊັດເຈນໃນ backend.

ຜູ້ໃດກໍຕາມທີ່ດໍາເນີນເວັບໄຊທ໌ WordPress ຮູ້ວ່າສິ່ງທີ່ໜ້າອຸກໃຈທີ່ສຸດບໍ່ແມ່ນການຂາດການເຂົ້າຊົມ, ແຕ່ເມື່ອເວັບໄຊທ໌ບໍ່ສາມາດເຂົ້າເຖິງໄດ້ຢ່າງກະທັນຫັນ, ດ້ວຍຂໍ້ຜິດພາດທີ່ສັບສົນເຊັ່ນ 500, 502, 503, ແລະ 504 ປາກົດຂຶ້ນຢູ່ໜ້າຈໍ.

ເຈົ້າຄິດວ່າເຊີບເວີຂັດຂ້ອງ ແລະ ຟ້າວໄປໂຕ້ຖຽງກັບຜູ້ໃຫ້ບໍລິການໂຮດຕິ້ງ, ແຕ່ຫຼັງຈາກເຂົາເຈົ້າກວດສອບແລ້ວ ເຈົ້າກໍ່ຮູ້ວ່າເຊີບເວີນັ້ນປົກກະຕິດີ.

ເຈົ້າອາດຄິດວ່າມັນເປັນການຂັດແຍ້ງຂອງປລັກອິນ, ດັ່ງນັ້ນເຈົ້າຈຶ່ງປິດການໃຊ້ງານ ແລະ ແກ້ໄຂບັນຫາເທື່ອລະອັນ, ໃຊ້ເວລາສ່ວນໃຫຍ່ໃນມື້ນັ້ນ, ແຕ່ຄວາມຜິດພາດຍັງຄົງເກີດຂຶ້ນເລື້ອຍໆ.

ຕົວຈິງແລ້ວ, ມັນບໍ່ຈຳເປັນຕ້ອງສັບສົນຂະໜາດນັ້ນ. ຫຼັງຈາກຕົກຢູ່ໃນກັບດັກທີ່ນັບບໍ່ຖ້ວນ, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າ 80% ຂອງຄວາມຜິດພາດເວັບໄຊທ໌ WP 5xx ບໍ່ສາມາດຫຼີກລ່ຽງຕົວການ 4 ຢ່າງນີ້ໄດ້. ແຕ່ລະອັນຖືກເຊື່ອງໄວ້ຢ່າງດີ, ແຕ່ມັນສາມາດທຳລາຍເວັບໄຊທ໌ຂອງທ່ານໄດ້ງ່າຍ.

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

ຜູ້ກະທຳຜິດ #1: WP-CRON ບໍ່ໄດ້ຖືກປິດໃຊ້ງານ, ໂດຍພື້ນຖານແລ້ວແມ່ນການຕິດຕັ້ງ "ການລະບາຍພະລັງງານທີ່ເຊື່ອງໄວ້" ຢູ່ໃນເວັບໄຊທ໌.

ຫຼາຍຄົນບໍ່ຮູ້ວ່າ WordPress ມີຄຸນສົມບັດກຳນົດເວລາວຽກທີ່ສ້າງຂຶ້ນມາໃນຕົວທີ່ເອີ້ນວ່າ WP-CRON, ເຊິ່ງຖືກເປີດໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ.

ໜ້າທີ່ຂອງມັນຟັງແລ້ວມີປະໂຫຍດຫຼາຍ, ເຊັ່ນ: ການກຳນົດເວລາການເຜີຍແຜ່ບົດຄວາມ, ການສຳຮອງຂໍ້ມູນອັດຕະໂນມັດ, ການກວດສອບການອັບເດດປລັກອິນ, ແລະແມ່ນແຕ່ການສົ່ງການແຈ້ງເຕືອນໃຫ້ສະມາຊິກ.

ແຕ່ເຈົ້າຮູ້ບໍ່ວ່າຄຸນສົມບັດທີ່ເປັນປະໂຫຍດນີ້ຕົວຈິງແລ້ວແມ່ນສາເຫດຫຼັກທີ່ເຮັດໃຫ້ເຊີບເວີຂັດຂ້ອງ ແລະ ເຮັດໃຫ້ເກີດຄວາມຜິດພາດ 5xx?

WP-CRON ແຕກຕ່າງຈາກ Cron ພື້ນເມືອງຂອງເຊີບເວີ. ມັນບໍ່ໄດ້ເຮັດວຽກຢ່າງຕັ້ງໜ້າ, ແຕ່ຖືກກະຕຸ້ນໂດຍການເຂົ້າຊົມຂອງຜູ້ໃຊ້. ທຸກໆຄັ້ງທີ່ຜູ້ໃຊ້ເຂົ້າຊົມເວັບໄຊທ໌ຂອງທ່ານ, ມັນຈະປະຕິບັດໄຟລ໌ /wp-cron.php ຢ່າງລັບໆເພື່ອກວດສອບວ່າມີໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ໃຫ້ເຮັດຫຼືບໍ່.

ນີ້ໝາຍຄວາມວ່າຜູ້ມາຢ້ຽມຢາມເວັບໄຊທ໌ຂອງທ່ານແຕ່ລະຄົນຈະເພີ່ມ "ພາລະພິເສດ", ແລະ ຍິ່ງທ່ານມີຜູ້ມາຢ້ຽມຢາມຫຼາຍເທົ່າໃດ, ພາລະກໍ່ຈະໜັກຂຶ້ນເທົ່ານັ້ນ.

ຂ້ອຍເຄີຍມີເວັບໄຊທ໌ທີ່ມີຜູ້ເຂົ້າຊົມຫຼາຍກວ່າໜຶ່ງພັນຄົນຕໍ່ມື້. ເມື່ອ WP-CRON ບໍ່ໄດ້ຖືກປິດໃຊ້ງານ, ການໃຊ້ CPU ຂອງເຊີບເວີມັກຈະເພີ່ມຂຶ້ນເປັນຫຼາຍກວ່າ 80%, ແລະຈະມີຢ່າງໜ້ອຍສອງຂໍ້ຜິດພາດ 503 ໃນແຕ່ລະມື້, ໂດຍຜູ້ເຂົ້າຊົມຈະຖືກໂອນໄປຫາໜ້າຂໍ້ຜິດພາດທັນທີທີ່ພວກເຂົາຄລິກໃສ່ມັນ.

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

ເອກະສານ GitHub ລະບຸຢ່າງຊັດເຈນວ່າ: "ລະຫັດຕອບສະໜອງ HTTP ທີ່ບໍ່ຄາດຄິດ: 500 ຫຼືສູງກວ່າ, ນີ້ໝາຍຄວາມວ່າມີຂໍ້ຜິດພາດເກີດຂຶ້ນໃນເຊີບເວີຂອງທ່ານເຊິ່ງເຮັດໃຫ້ cron spawner ເຮັດວຽກບໍ່ໄດ້." ນີ້ໝາຍຄວາມວ່າເມື່ອ WP-CRON ເຮັດວຽກບໍ່ຖືກຕ້ອງ, ມັນຈະເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດຂອງເຊີບເວີ 500 ຫຼືສູງກວ່າ.

ວິທີການທີ່ຖືກຕ້ອງແມ່ນການປິດໃຊ້ງານ WP-CRON ເລີ່ມຕົ້ນ ແລະ ໃຊ້ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ເດີມຂອງເຊີບເວີແທນ. ນີ້ຈະຮັບປະກັນວ່າໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ຈະດຳເນີນການຕາມປົກກະຕິ ໃນຂະນະທີ່ຫຼຸດຜ່ອນພາລະຂອງເຊີບເວີ.

ຖ້າເຊີບເວີຂອງທ່ານຮອງຮັບຄຳສັ່ງ curl, ທ່ານສາມາດເພີ່ມໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ໂດຍກົງແບບນີ້ (ດັດແປງຕາມໂດເມນເວັບໄຊທ໌ຂອງທ່ານ):

*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

ຄຳສັ່ງນີ້ຈະປະຕິບັດໜ້າວຽກ WP-CRON ທຸກໆ 15 ນາທີ, ເໝາະສຳລັບເວັບໄຊທ໌ຂະໜາດນ້ອຍ ແລະ ຂະໜາດກາງສ່ວນໃຫຍ່; ຖ້າເວັບໄຊທ໌ຂອງທ່ານມີໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ເລື້ອຍໆ, ທ່ານຍັງສາມາດໃຊ້ສິ່ງນີ້ໄດ້:

*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

ຫຼັງຈາກຂ້ອຍປິດການໃຊ້ງານ WP-CRON ແລະຕັ້ງຄ່າໜ້າວຽກຕາມກຳນົດເວລາໄວ້ໃນເຊີບເວີ, ການໃຊ້ CPU ຂອງເຊີບເວີໄດ້ຫຼຸດລົງຕໍ່າກວ່າ 30%, ແລະບໍ່ມີຂໍ້ຜິດພາດ 503 ຢ່າງເປັນເວລາໜຶ່ງເດືອນ. ອັດຕາການຮັກສາຜູ້ມາຢ້ຽມຢາມຍັງເພີ່ມຂຶ້ນ 18%.

ຜູ້ກະທຳຜິດອັນດັບສອງ: ໜ້າວຽກທີ່ກຳນົດເວລາ CRON ຊ້ຳໆ ແລະ ໄຟລ໌ທີ່ເຫຼືອຫຼັງຈາກການຖອນການຕິດຕັ້ງປລັກອິນໂດຍພື້ນຖານແລ້ວແມ່ນ "ປະໄວ້ຂີ້ເຫຍື້ອ" ຢູ່ໃນເວັບໄຊທ໌.

ການແກ້ໄຂບັນຫາ WP-CRON ບໍ່ໄດ້ໝາຍຄວາມວ່າທ່ານສາມາດພັກຜ່ອນໄດ້ຢ່າງສະບາຍ; ມັນມີອຸປະສັກທີ່ເຊື່ອງໄວ້ທີ່ເຈົ້າຂອງເວັບໄຊທ໌ຫຼາຍຄົນມອງຂ້າມ.

ນີ້ໝາຍຄວາມວ່າໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ຂອງ CRON ກຳລັງເຮັດວຽກຊ້ຳໆ, ຫຼື ໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ທີ່ຍັງເຫຼືອຍັງຄົງເຮັດວຽກຢ່າງລັບໆຫຼັງຈາກຖອນການຕິດຕັ້ງປລັກອິນ.

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

ນີ້ແມ່ນເກີດຈາກໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ທີ່ຍັງເຫຼືອຈາກປລັກອິນ.

ຕົວຢ່າງ, ຖ້າປລັກອິນສ້າງໜ້າວຽກທີ່ກຳນົດເວລາປະຈຳວັນ, WordPress ຈະສືບຕໍ່ປະຕິບັດໜ້າວຽກນີ້ເຖິງແມ່ນວ່າປລັກອິນຈະຖືກຖອນການຕິດຕັ້ງແລ້ວກໍຕາມ. ໜ້າວຽກທີ່ກຳນົດເວລາດັ່ງກ່າວບໍ່ມີຄວາມໝາຍ. ໜ້າວຽກທີ່ເຫຼືອທີ່ບໍ່ມີຄວາມໝາຍເຫຼົ່ານີ້ຈະໃຊ້ຊັບພະຍາກອນເຊີບເວີຢ່າງຕໍ່ເນື່ອງ ແລະ ໃນທີ່ສຸດຈະນຳໄປສູ່ຄວາມຜິດພາດ.

ຮ້າຍແຮງກວ່ານັ້ນ, ບາງປລັກອິນສ້າງໜ້າວຽກທີ່ກຳນົດເວລາຊ້ຳໆຫຼາຍອັນໂດຍອັດຕະໂນມັດ. ຕົວຢ່າງ, ໜ້າວຽກ "ກວດສອບການອັບເດດປະຈຳວັນ" ອາດຈະຖືກສ້າງຂຶ້ນຫ້າຄັ້ງ, ແລະແຕ່ລະອັນຈະຖືກປະຕິບັດຕາມຕາຕະລາງເວລາ, ຊຶ່ງໝາຍຄວາມວ່າເຊີບເວີຈະຕ້ອງປະມວນຜົນໜ້າວຽກທີ່ຄືກັນຫ້າຢ່າງພ້ອມໆກັນ.

ຂ້ອຍເຄີຍຕິດຕັ້ງ ປລັກອິນ SEO ກ່ອນໜ້ານີ້ , ແລະຫຼັງຈາກຖອນການຕິດຕັ້ງມັນແລ້ວ, ຂ້ອຍບໍ່ໄດ້ສົນໃຈ. ເຄິ່ງເດືອນຕໍ່ມາ, ເວັບໄຊທ໌ຂອງຂ້ອຍມັກຈະພົບກັບຂໍ້ຜິດພາດ timeout 504 ຄັ້ງ. ຫຼັງຈາກກວດສອບບັນທຶກຂອງເຊີບເວີ, ຂ້ອຍໄດ້ຄົ້ນພົບວ່າປລັກອິນໄດ້ປະໄວ້ໜ້າວຽກທີ່ກຳນົດໄວ້ປະຈຳວັນສາມຢ່າງ, ແຕ່ລະອັນມີເວລາປະຕິບັດ 12 ວິນາທີ. ການປະຕິບັດໜ້າວຽກທັງສາມຢ່າງພ້ອມໆກັນເຮັດໃຫ້ການຕອບສະໜອງຂອງເຊີບເວີໝົດເວລາໂດຍກົງ.

ສິ່ງທີ່ໜ້າຢ້ານກວ່ານັ້ນກໍຄື ໜ້າວຽກທີ່ຍັງເຫຼືອ ແລະ ເກີດຂຶ້ນຊ້ຳໆເຫຼົ່ານີ້ ເບິ່ງບໍ່ເຫັນ ຢູ່ໃນ backend ຂອງ WordPress , ແລະ ເຈົ້າບໍ່ຮູ້ວ່າພວກມັນກຳລັງເຮັດວຽກຢ່າງລັບໆ.

ເຖິງຢ່າງໃດກໍ່ຕາມ, ມີວິທີແກ້ໄຂ: ປລັກອິນ WP-Crontrol ສາມາດຈັດການມັນໄດ້ຢ່າງສົມບູນແບບ. ມັນເປັນເຄື່ອງມືການຈັດການໜ້າວຽກ Cron ຢ່າງເປັນທາງການທີ່ແນະນຳໂດຍ WordPress, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເບິ່ງ, ແກ້ໄຂ ແລະ ລຶບໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ທັງໝົດໄດ້ໂດຍກົງໃນ backend.

ອີງຕາມຄຳອະທິບາຍຂອງປລັກອິນ WordPress, WP-Crontrol ສາມາດ "ເບິ່ງເຫດການ cron ທີ່ກຳນົດເວລາໄວ້ທັງໝົດ, ແກ້ໄຂ, ລຶບ, ຢຸດຊົ່ວຄາວ, ສືບຕໍ່, ແລະ ແລ່ນເຫດການ cron ທັນທີ." ເວົ້າອີກຢ່າງໜຶ່ງ, ມັນສາມາດເບິ່ງໜ້າວຽກທີ່ກຳນົດເວລາໄວ້ທັງໝົດ ແລະ ລຶບໜ້າວຽກທີ່ຊໍ້າກັນ ຫຼື ບໍ່ຖືກຕ້ອງ. ມັນໃຊ້ງ່າຍຫຼາຍ ແລະ ບໍ່ຕ້ອງການຂຽນລະຫັດແມ່ນແຕ່ແຖວດຽວ.

ຫຼັງຈາກໃຊ້ປລັກອິນນີ້ເພື່ອແກ້ໄຂບັນຫາ, ຂ້ອຍໄດ້ລຶບໜ້າວຽກທີ່ຊໍ້າກັນ 8 ໜ້າ ແລະ ໜ້າວຽກທີ່ເຫຼືອຂອງປລັກອິນ 5 ໜ້າ, ແລະ ຄວາມໄວໃນການຕອບສະໜອງຂອງເວັບໄຊທ໌ໄດ້ດີຂຶ້ນ 40% ໂດຍກົງ. ຄວາມຜິດພາດ 504 ບໍ່ເຄີຍເກີດຂຶ້ນອີກ.

ຄຳເຕືອນ: ເມື່ອລຶບໜ້າວຽກ, ໃຫ້ແນ່ໃຈວ່າໄດ້ກວດສອບຢ່າງລະອຽດ ແລະ ຫຼີກລ່ຽງການລຶບໜ້າວຽກຫຼັກທີ່ກຳນົດເວລາໄວ້ຂອງ WordPress ໂດຍບັງເອີນ, ເຊັ່ນ "wp_version_check" (ການກວດສອບເວີຊັນ). ການລຶບໂດຍບັງເອີນອາດເຮັດໃຫ້ເວັບໄຊທ໌ບໍ່ສາມາດອັບເດດໄດ້ຢ່າງຖືກຕ້ອງ.

ໃນຂະນະທີ່ປລັກອິນ WP-Crontrol ສາມາດລຶບໜ້າວຽກທີ່ຊໍ້າກັນ ຫຼື ໜ້າວຽກທີ່ບໍ່ຖືກຕ້ອງດ້ວຍຕົນເອງ, ມັນຕ້ອງການການແຊກແຊງດ້ວຍຕົນເອງ, ເຊິ່ງບໍ່ເໝາະສົມ...

ເຖິງຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາສາມາດເຮັດໃຫ້ຂະບວນການນີ້ເປັນອັດຕະໂນມັດໄດ້ໂດຍໃຊ້ລະຫັດ WordrPress. ເບິ່ງບົດແນະນຳຂ້າງລຸ່ມນີ້ສຳລັບລາຍລະອຽດ. ▼

🔗ເຄັດລັບການເລັ່ງຄວາມໄວເວັບໄຊທ໌ WordPress: ລຶບໜ້າວຽກ CRON ທີ່ກຳນົດເວລາໄວ້ບໍ່ຖືກຕ້ອງໂດຍອັດຕະໂນມັດ

ຜູ້ກະທຳຜິດ #3: ຖານຂໍ້ມູນຊໍ້າຊ້ອນໃນ WordPress

ໃນ WordPress, ໜຶ່ງໃນເຫດຜົນຂອງ ຄວາມຜິດພາດ 500 ແມ່ນຄວາມຊໍ້າຊ້ອນຂອງຖານຂໍ້ມູນ, ໂດຍສະເພາະຕາຕະລາງຂໍ້ມູນຂະໜາດໃຫຍ່ທີ່ສ້າງຂຶ້ນໂດຍ plugins ບາງອັນ.

ເມື່ອໃຊ້ປລັກອິນ WP optimization, ຂ້ອຍພົບວ່າຕາຕະລາງຂໍ້ມູນບາງອັນມີຂະໜາດໃຫຍ່ຜິດປົກກະຕິ, ໂດຍສະເພາະແມ່ນ ຕາຕະລາງການຕັ້ງຄ່າ Wordfence (wfconfig) .

ການວິເຄາະບັນຫາ

• wfconfig ມີຄວາມຊໍ້າຊ້ອນຂອງຕາຕະລາງຂໍ້ມູນທີ່ຮ້າຍແຮງ.ມັນເຄີຍຖືກທຳຄວາມສະອາດມາກ່ອນແລ້ວຄັ້ງໜຶ່ງ, ແຕ່ມັນກໍ່ປາກົດຂຶ້ນອີກຢ່າງໄວວາ.
• ບັນຫາເຄື່ອງຈັກເກັບຮັກສາຂໍ້ມູນເລີ່ມຕົ້ນຕາຕະລາງການຕັ້ງຄ່າ Wordfence ໃຊ້ເຄື່ອງຈັກ InnoDB ເລີ່ມຕົ້ນ, ເຊິ່ງຈະສະສົມຂໍ້ມູນທີ່ຊໍ້າຊ້ອນຫຼາຍຮ້ອຍ MB ຕາມການເວລາ.
• ຜົນກະທົບຕໍ່ປະສິດທິພາບຕາຕະລາງຂໍ້ມູນສາມາດມີຂະໜາດໃຫຍ່ເຖິງຫຼາຍຮ້ອຍ MB ໄດ້ຢ່າງງ່າຍດາຍ, ເຮັດໃຫ້ຄວາມໄວໃນການໂຫຼດເວັບໄຊທ໌ຫຼຸດລົງ ແລະ ແມ້ກະທັ້ງເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດ 500 ຢ່າງ.

ວິທີແກ້ໄຂ

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

ສຳລັບຄຳແນະນຳກ່ຽວກັບການປ່ຽນເຄື່ອງຈັກເກັບຂໍ້ມູນເລີ່ມຕົ້ນຂອງ MariaDB ເປັນ MyISAM ໂດຍໃຊ້ HestiaCP , ກະລຸນາອ້າງອີງເຖິງບົດແນະນຳຕໍ່ໄປນີ້:

ວິທີການປ່ຽນເຄື່ອງຈັກເກັບຮັກສາຄ່າເລີ່ມຕົ້ນຂອງ MariaDB ເປັນ MyISAM ໃນ HestiaCP? ວິທີແກ້ໄຂງ່າຍໆພຽງຂັ້ນຕອນດຽວ!

ຜູ້ກະທຳຜິດທີສີ່: ຄວາມຜິດພາດຫຼັງຈາກການອັບເກຣດປລັກອິນ/ຮູບແບບແມ່ນຄ້າຍຄືກັບການປະຕິບັດ "ການຜ່າຕັດທີ່ບໍ່ເປັນທາງການ" ຢູ່ໃນເວັບໄຊທ໌.

ເຈົ້າຂອງເວັບໄຊທ໌ຫຼາຍຄົນມີນິໄສຄລິກ "ອັບເດດ" ທັນທີເມື່ອພວກເຂົາເຫັນການກະຕຸ້ນການອັບເດດສຳລັບປລັກອິນ ຫຼື ຮູບແບບຕ່າງໆ, ໂດຍເຊື່ອວ່າການອັບເດດຈະແກ້ໄຂຊ່ອງໂຫວ່ ແລະ ປັບປຸງປະສິດທິພາບ.

ແຕ່ຄວາມຈິງແມ່ນກົງກັນຂ້າມ; ຂໍ້ຜິດພາດ 5xx ຫຼາຍຢ່າງແມ່ນເກີດຈາກການອັບເດດ plugins ຫຼື themes.

ຂ້ອຍເຄີຍພົບບັນຫານີ້ມາກ່ອນ. ເດືອນແລ້ວນີ້, ຂ້ອຍໄດ້ອັບເກຣດເວັບໄຊທ໌ຂອງຂ້ອຍດ້ວຍປລັກອິນສ້າງໜ້າເວັບທີ່ໄດ້ຮັບຄວາມນິຍົມ. ຫຼັງຈາກຄລິກອັບເດດ, ໜ້າເວັບກໍ່ກາຍເປັນຫວ່າງເປົ່າ, ແລະຫຼັງຈາກໂຫຼດຄືນໃໝ່, ຂໍ້ຜິດພາດ 500 Internal Server ໄດ້ປາກົດຂຶ້ນ, ເຮັດໃຫ້ມັນບໍ່ສາມາດເຂົ້າເຖິງ backend ໄດ້.

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

ຂໍ້ຜິດພາດຫຼັງຈາກການອັບເກຣດ plugin ຫຼື theme ແມ່ນສາເຫດທົ່ວໄປຂອງຂໍ້ຜິດພາດ WordPress 500, ໂດຍສະເພາະເມື່ອ plugin ເວີຊັນໃໝ່ມີຊ່ອງໂຫວ່ຂອງລະຫັດ ຫຼື ຂໍ້ຂັດແຍ່ງກັບ plugin ຫຼື theme ອື່ນໆໃນເວັບໄຊທ໌.

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

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

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

ຫຼາຍຄົນບໍ່ຮູ້ວິທີການຍ້ອນກັບ, ແຕ່ທ່ານບໍ່ຈຳເປັນຕ້ອງດາວໂຫຼດ ຫຼື ອັບໂຫລດໄຟລ໌ດ້ວຍຕົນເອງ; ປລັກອິນ WP Rollback ເຮັດໃຫ້ມັນງ່າຍດາຍ.

ອີງຕາມຄຳອະທິບາຍຂອງ WordPress, ປລັກອິນ WP Rollback ສາມາດ "ມ້ວນຄືນຮູບແບບ ຫຼື ປລັກອິນໃດໆຈາກ wordpress.org ໄປສູ່ລຸ້ນກ່ອນໜ້າ (ຫຼື ໃໝ່ກວ່າ) ໄດ້ຢ່າງວ່ອງໄວ ແລະ ງ່າຍດາຍໂດຍບໍ່ຕ້ອງມີການຊ່ວຍເຫຼືອໃດໆ." ເວົ້າອີກຢ່າງໜຶ່ງ, ມັນສາມາດປ່ຽນປລັກອິນ ຫຼື ຮູບແບບຕ່າງໆໄປສູ່ລຸ້ນກ່ອນໜ້ານີ້ໄດ້ດ້ວຍການຄລິກດຽວ, ໂດຍບໍ່ມີການດຳເນີນງານທີ່ສັບສົນ, ເຮັດໃຫ້ຜູ້ເລີ່ມຕົ້ນໃຊ້ງ່າຍ.

ຫຼັງຈາກການອັບເກຣດປລັກອິນຄັ້ງສຸດທ້າຍຂອງຂ້ອຍລົ້ມເຫຼວ, ຂ້ອຍໄດ້ໃຊ້ WP Rollback ເພື່ອກັບຄືນໄປໃຊ້ເວີຊັນກ່ອນໜ້ານີ້ດ້ວຍການຄລິກດຽວ. ເວັບໄຊທ໌ໄດ້ກັບຄືນສູ່ສະພາບປົກກະຕິພາຍໃນເວລາພຽງ 30 ວິນາທີ, ແລະບໍ່ມີຂໍ້ມູນໃດໆສູນເສຍໄປ.

ນີ້ແມ່ນຄຳແນະນຳ: ກ່ອນທີ່ຈະອັບເກຣດປລັກອິນ ຫຼື ຮູບແບບຕ່າງໆ, ໃຫ້ສຳຮອງຂໍ້ມູນເວັບໄຊທ໌ຂອງທ່ານກ່ອນສະເໝີ. ດີທີ່ສຸດທີ່ຈະທົດສອບມັນໃນສະພາບແວດລ້ອມການທົດສອບກ່ອນເພື່ອຮັບປະກັນວ່າບໍ່ມີບັນຫາກ່ອນທີ່ຈະອັບເດດມັນໃນເວັບໄຊທ໌ທາງການ, ເພື່ອຫຼີກເວັ້ນຂໍ້ຜິດພາດ.

ສະຫຼຸບ: ຮຽນຮູ້ 3 ຈຸດເຫຼົ່ານີ້ເພື່ອບອກລາຂໍ້ຜິດພາດ 5xx ຂອງເວັບໄຊທ໌ WP ຢ່າງສິ້ນເຊີງ.

ການໃຊ້ງານເວັບໄຊທ໌ WordPress, ຄວາມຜິດພາດ 500, 502, 503, ແລະ 504 ແມ່ນຄືກັບ "ອຸປະສັກ," ເບິ່ງຄືວ່າເປັນບັນຫາ, ແຕ່ສາເຫດຕົ້ນຕໍແມ່ນຂ້ອນຂ້າງຈະແຈ້ງ - ມັນບໍ່ແມ່ນວ່າເຊີບເວີມີຂໍ້ບົກຜ່ອງ, ແລະກໍ່ບໍ່ມີບັນຫາໃຫຍ່ກັບໂປຣແກຣມເວັບໄຊທ໌, ແຕ່ພວກເຮົາມອງຂ້າມລາຍລະອຽດສາມຢ່າງຄື: WP-CRON, ໜ້າວຽກທີ່ກຳນົດໄວ້ທີ່ຍັງເຫຼືອ, ແລະ ການອັບເກຣດປລັກອິນ/ຮູບແບບ.

ໃນຖານະທີ່ເຈົ້າຂອງເວັບໄຊທ໌ WordPress, ຕັ້ງແຕ່ຖືກຄອບງຳດ້ວຍຄວາມຜິດພາດໃນຕອນເລີ່ມຕົ້ນຈົນເຖິງຕອນນີ້ສາມາດແກ້ໄຂບັນຫາ ແລະ ແກ້ໄຂຄວາມຜິດພາດ 5xx ທັງໝົດໄດ້ຢ່າງວ່ອງໄວ, ສິ່ງທີ່ຂ້ອຍໄດ້ຮຽນຮູ້ທີ່ໃຫຍ່ທີ່ສຸດແມ່ນວ່າການດຳເນີນງານຂອງເວັບໄຊທ໌ທີ່ໝັ້ນຄົງບໍ່ໄດ້ອີງໃສ່ "ການລັອກປະຕູຄອກມ້າຫຼັງຈາກມ້າແລ່ນໜີໄປແລ້ວ," ແຕ່ແມ່ນຂຶ້ນກັບ "ການປ້ອງກັນດີກ່ວາການແກ້ໄຂ."

ເຈົ້າຂອງເວັບໄຊທ໌ຫຼາຍຄົນຄິດວ່າລາຍລະອຽດເລັກໆນ້ອຍໆເຫຼົ່ານີ້ບໍ່ສຳຄັນ, ແລະ ຈະເສຍໃຈທີ່ບໍ່ໄດ້ກວດສອບລ່ວງໜ້າເມື່ອເວັບໄຊທ໌ເກີດບັນຫາ, ສູນເສຍການເຂົ້າຊົມ, ແລະ ສູນເສຍລາຍໄດ້.

ມັນເປັນສິ່ງສຳຄັນທີ່ຕ້ອງເຂົ້າໃຈວ່າສຳລັບເວັບໄຊທ໌, "ຄວາມໝັ້ນຄົງ" ແມ່ນຂໍ້ໄດ້ປຽບດ້ານການແຂ່ງຂັນຫຼັກ. ຄວາມຜິດພາດ 5xx ດຽວສາມາດເຮັດໃຫ້ທ່ານສູນເສຍຜູ້ມາຢ້ຽມຢາມ 10%, ແລະຄວາມຜິດພາດຫຼາຍຄັ້ງສາມາດເຮັດໃຫ້ອັນດັບຂອງເຄື່ອງຈັກຊອກຫາຫຼຸດລົງ, ເຮັດໃຫ້ຄວາມພະຍາຍາມ SEO ກ່ອນໜ້ານີ້ທັງໝົດຂອງທ່ານເສຍໄປ.

ດັ່ງທີ່ຄຳເວົ້າທີ່ວ່າ, "ຄັນຄູນ້ຳຍາວພັນໄມລ໌ສາມາດຖືກເຈາະໄດ້ໂດຍຮູມົດ." ຄວາມຜິດພາດຂອງເວັບໄຊທ໌ WP 5xx ບໍ່ເຄີຍປາກົດຂຶ້ນຢ່າງກະທັນຫັນ, ແຕ່ເປັນຜົນມາຈາກການສະສົມບັນຫານ້ອຍໆ - WP-CRON ທີ່ບໍ່ຖືກປິດໃຊ້ງານ, ໜ້າວຽກທີ່ກຳນົດໄວ້ທີ່ຍັງເຫຼືອ, ແລະ ການດຳເນີນການອັບເກຣດທີ່ຮີບດ່ວນ. "ຮູມົດ" ທີ່ເບິ່ງຄືວ່າບໍ່ສຳຄັນເຫຼົ່ານີ້ໃນທີ່ສຸດຈະທຳລາຍ "ຄັນຄູນ້ຳ" ຂອງເວັບໄຊທ໌ທັງໝົດ.

ການດຳເນີນງານທີ່ມີປະສິດທິພາບຢ່າງແທ້ຈິງໝາຍເຖິງການແກ້ໄຂບັນຫາຕ່າງໆຕັ້ງແຕ່ຕົ້ນ.

1. ປິດການໃຊ້ງານ WP-CRON ເລີ່ມຕົ້ນ ແລະ ປ່ຽນມັນດ້ວຍໜ້າວຽກທີ່ກຳນົດເວລາໂດຍອີງໃສ່ເຊີບເວີ;
2. ໃຊ້ WP-Crontrol ເປັນປະຈຳເພື່ອເຮັດຄວາມສະອາດໜ້າວຽກທີ່ຊໍ້າຊ້ອນ ແລະ ຕົກຄ້າງຕາມກຳນົດເວລາ;
3. ໃຫ້ແນ່ໃຈວ່າໄດ້ສຳຮອງຂໍ້ມູນຂອງທ່ານກ່ອນທີ່ຈະອັບເກຣດປລັກອິນ ຫຼື ຮູບແບບຕ່າງໆ, ແລະ ຍົກເລີກທັນທີຖ້າເກີດຂໍ້ຜິດພາດຂຶ້ນ.

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

ທຸກໆການໂຫຼດທີ່ໝັ້ນຄົງຂອງເວັບໄຊທ໌ຂອງທ່ານ ແລະ ທຸກໆການພັກເຊົາຂອງຜູ້ມາຢ້ຽມຢາມແມ່ນຊັບສິນທີ່ມີຄຸນຄ່າທີ່ທ່ານສະສົມໄວ້ໃນໄລຍະເວລາ.

ຕັ້ງແຕ່ນີ້ໄປ, ໃຫ້ລະບຸສາມສາເຫດນີ້ ແລະ ປະຕິບັດການບຳລຸງຮັກສາປະຈຳວັນເພື່ອຮັບປະກັນວ່າເວັບໄຊທ໌ WordPress ຂອງທ່ານບໍ່ພຽງແຕ່ສາມາດຮັບມືກັບການເຮັດວຽກໜັກຂອງທ່ານໄດ້ເທົ່ານັ້ນ ແຕ່ຍັງສາມາດເພີ່ມການເຂົ້າຊົມ ແລະ ລາຍໄດ້ຢ່າງຕໍ່ເນື່ອງ.

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