Зашто 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 клијента радника.