PHP-FPM आपके टर्मिनल में काम करने वाला प्रॉक्सी क्यों खो देता है

एक ही PHP फ़ाइल टर्मिनल में प्रॉक्सी का उपयोग कर सकती है और PHP-FPM द्वारा परोसी जाने पर सीधे जा सकती है। इसे चलाने वाली प्रक्रियाओं की तुलना से शुरू करें। आपका टर्मिनल PHP को अपने शेल वातावरण के साथ शुरू करता है; वेब सर्वर उन वर्कर को अनुरोध भेजता है जो FPM पहले ही बना चुका है।

वर्कर के वातावरण को देखें

FPM पूल कॉन्फ़िगरेशन clear_env और स्पष्ट env[NAME] प्रविष्टियाँ प्रदान करता है। वातावरण सफ़ाई सक्षम होने पर, आपके लॉगिन शेल में वेरिएबल निर्यात करने से वह वर्कर में नहीं पहुँचता। पूल प्रविष्टियाँ चुने हुए वेरिएबल पास कर सकती हैं:

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 को समान मान मिलते हैं पर व्यवहार अलग रहता है, तो आगे क्लाइंट विकल्पों और बायपास नियमों की तुलना करें। शेल प्रोफ़ाइल को बार-बार संपादित करना वर्कर के HTTP क्लाइंट के भीतर के अंतर को नहीं सुलझा सकता।