Hvers vegna PHP-FPM tapar proxyinu sem virkar í flugstöðinni þinni

Sama PHP skráin getur notað proxy í flugstöð og farið beint þegar PHP-FPM þjónar henni. Byrjaðu á að bera saman ferlin sem keyra hana. Flugstöðin þín ræsir PHP með umhverfi skeljarinnar; vefþjónninn sendir beiðni til vinnuferla sem FPM hefur þegar búið til.

Skoðaðu umhverfi vinnuferilsins

FPM laugstillingin veitir clear_env og skýrar env[NAME] færslur. Þegar hreinsun umhverfis er virk setur útflutningur breytu í innskráningarskelinni þína hana ekki í vinnuferil. Laugfærslur geta sent valdar breytur:

env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080

Beittu stillingarbreytingum með venjulegri FPM endurhleðsluaðferð dreifingarinnar. Settu gildin í laugina sem þjónar forritinu í raun. Önnur laug, þjónustureikningur eða gámur getur útskýrt hvers vegna svo virðist rétt breyting hafi engin áhrif.

Þegar þú kembir lifandi beiðni skaltu aðeins athuga hvort væntu stillingarnar séu til staðar. Opinber greiningarsíða sem prentar út full umhverfisgildi getur afhjúpað proxy-auðkenni ásamt ótengdum leyndarmálum.

Athugaðu síðan PHP flutninginn

libcurl hefur skjalfesta meðhöndlun proxy-umhverfis; skýrt PHP cURL handfang hefur líka sína eigin valkosti. HTTP straumvafningur PHP hefur aðskilda samhengisstillingu. Að gefa vinnuferli breytur gerir það ekki að öll PHP netforritaskil noti þær.

Það gefur gagnlega tvíþætta athugun: staðfestu hvað vinnuferillinn fékk, staðfestu síðan hvernig valinn HTTP biðlari les proxy-stillingar. Ef CLI og FPM fá sömu gildin en hegða sér samt öðruvísi skaltu næst bera saman valkosti biðlarans og framhjáhlaupsreglur. Endurteknar breytingar á skeljarprófílnum geta ekki leyst mun inni í HTTP biðlara vinnuferilsins.