কেন 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 ক্লায়েন্টের ভেতরের পার্থক্য মিটাতে পারে না।