Эмне үчүн PHP-FPM терминалда иштеген проксини жоготот
Прокси конфигурациясын PHP-FPM жумушчуларына чейин көзөмөлдөп, алардын чөйрөсүн PHP агымынын контексттеринен ажыратыңыз.
Бир 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 кардарынын ичиндеги айырманы чече албайт.