Чаму 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 таксама мае свае параметры. Абгортка HTTP-патоку PHP мае асобную канфігурацыю кантэксту. Забеспячэнне працоўнага працэсу зменнымі не прымушае кожны сеткавы API PHP іх спажываць.

Гэта дае карысную двухчастковую праверку: пацвердзіце, што атрымаў працоўны працэс, затым пацвердзіце, як выбраны HTTP-кліент чытае налады проксі. Калі CLI і FPM атрымліваюць аднолькавыя значэнні, але ўсё яшчэ паводзяць сябе па-рознаму, далей параўнайце параметры кліента і правілы абыходу. Паўторнае рэдагаванне профілю абалонкі не можа вырашыць розніцу ўнутры HTTP-кліента працоўнага працэсу.