چرا 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 مدیریت محیط پراکسی مستندشده‌ای دارد؛ یک دسته cURL صریح PHP هم گزینه‌های خودش را دارد. پوشش جریان HTTP در PHP پیکربندی زمینه جداگانه‌ای دارد. دادن متغیرها به یک کارگر باعث نمی‌شود هر API شبکه‌ای PHP آن‌ها را مصرف کند.

این یک بررسی دو بخشی مفید می‌دهد: تأیید کنید کارگر چه دریافت کرده، سپس تأیید کنید کلاینت HTTP انتخاب‌شده چگونه تنظیمات پراکسی را می‌خواند. اگر CLI و FPM مقادیر یکسانی دریافت می‌کنند اما هنوز متفاوت رفتار می‌کنند، در مرحله بعد گزینه‌های کلاینت و قواعد عبور را مقایسه کنید. ویرایش مکرر نمایه پوسته نمی‌تواند تفاوت درون کلاینت HTTP کارگر را حل کند.