ເປັນຫຍັງ PHP-FPM ຈຶ່ງເສຍ proxy ທີ່ເຮັດວຽກໃນ terminal ຂອງທ່ານ
ຕິດຕາມການຕັ້ງຄ່າ proxy ເຂົ້າໄປໃນ worker ຂອງ PHP-FPM ແລະ ແຍກສະພາບແວດລ້ອມຂອງພວກມັນອອກຈາກ context ຂອງ PHP stream.
ໄຟລ໌ PHP ດຽວກັນສາມາດໃຊ້ proxy ໃນ terminal ແລະ ໄປທາງກົງເມື່ອ PHP-FPM ໃຫ້ບໍລິການ. ເລີ່ມຈາກການປຽບທຽບ process ທີ່ລັນມັນ. Terminal ຂອງທ່ານເລີ່ມ PHP ດ້ວຍສະພາບແວດລ້ອມ shell; webserver ສົ່ງຄຳຂໍໄປຫາ worker ທີ່ FPM ສ້າງໄວ້ແລ້ວ.
ເບິ່ງສະພາບແວດລ້ອມຂອງ worker
ການຕັ້ງຄ່າ pool ຂອງ FPM ໃຫ້ clear_env ແລະ ລາຍການ env[NAME] ທີ່ຊັດເຈນ. ເມື່ອເປີດການລຶບສະພາບແວດລ້ອມ, ການ export ຕົວແປໃນ shell ເຂົ້າສູ່ລະບົບຈະບໍ່ວາງມັນໄວ້ໃນ worker. ລາຍການ pool ສາມາດສົ່ງຕົວແປທີ່ເລືອກ:
env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080ໃຊ້ການປ່ຽນແປງການຕັ້ງຄ່າຜ່ານຂັ້ນຕອນການ reload FPM ປົກກະຕິຂອງ deployment ຂອງທ່ານ. ໃສ່ຄ່າໃນ pool ທີ່ໃຫ້ບໍລິການ application ຕົວຈິງ. pool, ບັນຊີບໍລິການ ຫຼື container ອື່ນສາມາດອະທິບາຍວ່າເປັນຫຍັງການແກ້ໄຂທີ່ເບິ່ງຄືວ່າຖືກຕ້ອງຈຶ່ງບໍ່ມີຜົນ.
ເມື່ອ debug ຄຳຂໍທີ່ມີຊີວິດ, ກວດພຽງແຕ່ວ່າການຕັ້ງຄ່າທີ່ຄາດຫວັງມີຢູ່ຫຼືບໍ່. ໜ້າວິນິດໄສສາທາລະນະທີ່ພິມຄ່າສະພາບແວດລ້ອມທັງໝົດອາດເປີດເຜີຍຂໍ້ມູນຢືນຢັນຕົວຕົນຂອງ proxy ພ້ອມກັບຄວາມລັບທີ່ບໍ່ກ່ຽວຂ້ອງ.
ຈາກນັ້ນກວດການຂົນສົ່ງ PHP
libcurl ມີການຈັດການສະພາບແວດລ້ອມ proxy ທີ່ບັນທຶກໄວ້; handle PHP cURL ທີ່ຊັດເຈນ ກໍມີຕົວເລືອກຂອງຕົນເອງ. wrapper HTTP stream ຂອງ PHP ມີການຕັ້ງຄ່າ context ແຍກຕ່າງຫາກ. ການໃຫ້ຕົວແປແກ່ worker ບໍ່ໄດ້ເຮັດໃຫ້ທຸກ API ເຄືອຂ່າຍຂອງ PHP ໃຊ້ພວກມັນ.
ສິ່ງນີ້ໃຫ້ການກວດສອງສອງພາກສ່ວນທີ່ເປັນປະໂຫຍດ: ຢືນຢັນວ່າ worker ໄດ້ຮັບຫຍັງ, ແລ້ວຢືນຢັນວ່າ HTTP client ທີ່ເລືອກອ່ານການຕັ້ງຄ່າ proxy ແນວໃດ. ຖ້າ CLI ແລະ FPM ໄດ້ຮັບຄ່າດຽວກັນແຕ່ຍັງປະພຶດຕົວຕ່າງກັນ, ຈາກນັ້ນປຽບທຽບຕົວເລືອກ client ແລະ ກົດລະບຽບການຂ້າມ. ການແກ້ໄຂ shell profile ຊ້ຳໆບໍ່ສາມາດແກ້ຄວາມແຕກຕ່າງພາຍໃນ HTTP client ຂອງ worker ໄດ້.