Zakaj PHP-FPM izgubi proxy, ki deluje v vašem terminalu

Ista datoteka PHP lahko v terminalu uporablja proxy, pod PHP-FPM pa gre neposredno. Začnite s primerjavo procesov, ki jo izvajajo. Terminal zažene PHP z okoljem lupine; spletni strežnik pošlje zahtevo delavcem, ki jih je FPM že ustvaril.

Poglejte okolje delavca

Konfiguracija bazena FPM ponuja clear_env in izrecne vnose env[NAME]. Ob vključenem čiščenju okolja izvoz spremenljivke v prijavni lupini te ne postavi v delavca. Vnosi bazena lahko posredujejo izbrane spremenljivke:

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

Spremembe konfiguracije uveljavite z običajnim postopkom ponovnega nalaganja FPM v vaši namestitvi. Vrednosti vstavite v bazen, ki aplikacijo dejansko streže. Drug bazen, servisni račun ali vsebnik lahko pojasni, zakaj na videz pravilna sprememba nima učinka.

Pri odpravljanju napak v živi zahtevi preverite le, ali pričakovane nastavitve obstajajo. Javna diagnostična stran, ki izpisuje celotne vrednosti okolja, lahko razkrije poverilnice proxy skupaj z nepovezanimi skrivnostmi.

Nato preverite transport PHP

libcurl ima dokumentirano obravnavo proxy okolja; izrecni ročaj PHP cURL ima tudi svoje možnosti. Ovojnica toka HTTP v PHP ima ločeno konfiguracijo konteksta. Posredovanje spremenljivk delavcu ne pomeni, da jih bo porabil vsak omrežni API PHP.

To da koristno dvodelno preverjanje: potrdite, kaj je delavec prejel, nato pa, kako izbrani odjemalec HTTP bere nastavitve proxy. Če CLI in FPM prejmeta enake vrednosti, a se še vedno obnašata drugače, nato primerjajte možnosti odjemalca in pravila obhoda. Ponavljajoče urejanje profila lupine ne more razrešiti razlike znotraj odjemalca HTTP delavca.