HTTP 504 Gateway Timeout ກັບ timeout ຂອງ client ຂອງທ່ານ
ແຍກຄຳຮ້ອງຂອງ upstream ທີ່ໝົດເວລາຢູ່ gateway ອອກຈາກ timeout ທີ່ຕັ້ງໄວ້ໃນ client proxy ຂອງທ່ານ.
Client ຂອງທ່ານພ້ອມລໍຖ້າຫົກສິບວິນາທີ. ສິບວິນາທີຕໍ່ມາ ມັນໄດ້ຮັບ HTTP 504. ການເພີ່ມ timeout ຂອງ client ເປັນສອງນາທີບໍ່ໄດ້ໃຫ້ gateway ຫ້າສິບວິນາທີເພີ່ມເຕີມເພື່ອເຮັດວຽກ.
504 ອະທິບາຍ gateway ຫຼື proxy ທີ່ບໍ່ໄດ້ຮັບການຕອບສະໜອງຈາກ upstream ຕາມເວລາ ໃນຂະນະທີ່ພະຍາຍາມເຮັດຄຳຮ້ອງໃຫ້ສຳເລັດ. Gateway ໄດ້ຕັດສິນໃຈແລ້ວ ແລະ ສົ່ງການຕອບສະໜອງກັບມາ. Client ຂອງທ່ານສາມາດອ່ານການຕອບສະໜອງນັ້ນໄດ້ຢ່າງປົກກະຕິ.
ຕົວກາງໃດເປັນຜູ້ສົ່ງກັບມາ?
proxy ທາງໜ້າອາດເປັນຜູ້ອອກ. gateway ພາຍຫຼັງທີ່ເວັບໄຊດຳເນີນການກໍອາດເປັນໄດ້. ດ້ວຍ TLS ແບບປາຍຕໍ່ປາຍປົກກະຕິພາຍໃນ CONNECT, ການຕອບສະໜອງ HTTP ຈາກການແລກປ່ຽນກັບປາຍທາງທີ່ຖືກປົກປ້ອງນັ້ນບໍ່ຄືກັບ ການປະຕິເສດ CONNECT ເອງ.
ເກັບຂັ້ນຕອນ, ຫົວຂໍ້ການຕອບສະໜອງ, ຂໍ້ຄວາມໃນໜ້າຂໍ້ຜິດພາດ ແລະ log ທີ່ກົງກັນເມື່ອມີ. ຊື່ເຊີບເວີອາດເປັນຂໍ້ບົ່ງຊີ້ ແຕ່ບໍ່ຄວນຖືວ່າເປັນການລະບຸທີ່ບໍ່ຜິດພາດ. ເສັ້ນທາງອາດມີຕົວກາງຫຼາຍກວ່າອັນທີ່ຕັ້ງໄວ້ໃນ client ຂອງທ່ານ.
ຈາກນັ້ນກວດເບິ່ງວ່າເປັນຫຍັງການດຳເນີນການກັບ upstream ນັ້ນຈຶ່ງບໍ່ສຳເລັດ. ການເຂົ້າເຖິງ, ບໍລິການທີ່ຮັບໜັກເກີນ, ຕົວຄຳຮ້ອງທີ່ upstream ບໍ່ສາມາດປະມວນຜົນໄດ້ຕາມທີ່ຄາດຫວັງ ແລະ ພຶດຕິກຳຂອງແອັບພລິເຄຊັນ ລ້ວນແຕ່ສຳຄັນໄດ້. ສະຖານະເປັນໂຕເລກຢ່າງດຽວບໍ່ພິສູດວ່າການປ່ຽນ User-Agent ຫຼື ການເພີ່ມຕົວເລືອກ timeout ໜຶ່ງອັນເປັນວິທີແກ້ໄຂສາກົນ.
ປຽບທຽບຄຳຮ້ອງດຽວກັນ
ເມື່ອເຄື່ອງມືອື່ນໃຊ້ໄດ້ ໃຫ້ປຽບທຽບວິທີ, ເປົ້າໝາຍ, ການເຂົ້າລະຫັດຕົວ, ການພິສູດຕົວຕົນ ແລະ ເສັ້ນທາງ. "URL ເປີດໃນເບຣົາເຊີ" ບໍ່ແມ່ນການປຽບທຽບຄົບຖ້ວນກັບການສົ່ງ multipart ຜ່ານ client ບໍລິການ.
ຖ້າທ່ານດຳເນີນການ gateway ທີ່ອອກນັ້ນ ໃຫ້ປັບງົບ upstream ຂອງມັນໃຫ້ສອດຄ່ອງກັບພາລະວຽກທີ່ຮອງຮັບ ແລະ ກຳນົດເວລາອ້ອມຂ້າງ. ຖ້າບໍ່ດັ່ງນັ້ນ ໃຫ້ເກັບຜົນຂອງມັນໄວ້ເປັນຫຼັກຖານ ແລະ ໃຊ້ເສັ້ນທາງການເຂົ້າເຖິງ ຫຼື ການສະໜັບສະໜູນທີ່ເອກະສານໄວ້ຂອງຜູ້ດຳເນີນການ. ການລໍຖ້າດົນກວ່າໃນເຄື່ອງທ່ານເອງບໍ່ສາມາດປ່ຽນການຕອບສະໜອງທີ່ມາຮອດແລ້ວໄດ້.