რატომ კარგავს PHP-FPM პროქსის, რომელიც თქვენს ტერმინალში მუშაობს

ერთი და იგივე PHP ფაილს შეუძლია ტერმინალში პროქსის გამოყენება და პირდაპირ დაკავშირება, როცა მას PHP-FPM ემსახურება. დაიწყეთ იმ პროცესების შედარებით, რომლებიც მას ამუშავებენ. თქვენი ტერმინალი PHP-ს საკუთარი shell-ის გარემოთი უშვებს; ვებ სერვერი მოთხოვნას უგზავნის მუშებს, რომლებიც FPM-მა უკვე შექმნა.

შეხედეთ მუშის გარემოს

FPM-ის პულის კონფიგურაცია იძლევა clear_env-ს და ცხად env[NAME] ჩანაწერებს. გარემოს გასუფთავების ჩართვისას, თქვენი შესვლის shell-ში ცვლადის ექსპორტი მას მუშში არ ათავსებს. პულის ჩანაწერებს შეუძლიათ შერჩეული ცვლადების გადაცემა:

env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080

გამოიყენეთ კონფიგურაციის ცვლილებები თქვენი განლაგების ჩვეული FPM-ის გადატვირთვის პროცედურით. ჩასვით მნიშვნელობები იმ პულში, რომელიც ნამდვილად ემსახურება აპლიკაციას. სხვა პულმა, სერვისის ანგარიშმა ან კონტეინერმა შეიძლება ახსნას, რატომ არ აქვს ერთი შეხედვით სწორ რედაქტირებას ეფექტი.

ცოცხალი მოთხოვნის გამართვისას შეამოწმეთ მხოლოდ ის, არსებობს თუ არა მოსალოდნელი პარამეტრები. საჯარო დიაგნოსტიკური გვერდი, რომელიც სრულ გარემოს მნიშვნელობებს ბეჭდავს, შეიძლება გამოამჟღავნოს პროქსის სერტიფიკატები და დაუკავშირებელი საიდუმლოებები.

შემდეგ შეამოწმეთ PHP ტრანსპორტი

libcurl-ს აქვს დოკუმენტირებული პროქსის გარემოს დამუშავება; ცხად PHP cURL სახელურს ასევე აქვს თავისი პარამეტრები. PHP-ის HTTP ნაკადის გადასაფარებელს აქვს ცალკე კონტექსტის კონფიგურაცია. მუშისთვის ცვლადების მიწოდება არ იწვევს იმას, რომ PHP-ის ყველა ქსელური API მათ იყენებდეს.

ეს იძლევა სასარგებლო ორნაწილიან შემოწმებას: დაადასტურეთ, რა მიიღო მუშამ, შემდეგ დაადასტურეთ, როგორ კითხულობს არჩეული HTTP კლიენტი პროქსის პარამეტრებს. თუ CLI და FPM ერთსა და იმავე მნიშვნელობებს იღებენ, მაგრამ მაინც განსხვავებულად იქცევიან, შემდეგ შეადარეთ კლიენტის პარამეტრები და გვერდის ავლის წესები. shell-ის პროფილის განმეორებითი რედაქტირება ვერ გადაჭრის განსხვავებას მუშის HTTP კლიენტის შიგნით.