Hvorfor PHP-FPM mister den proxy, der virker i din terminal

Den samme PHP-fil kan bruge en proxy i en terminal og gå direkte, når den serveres af PHP-FPM. Begynd med at sammenligne de processer, der kører den. Din terminal starter PHP med sit shell-miljø; webserveren sender en anmodning til arbejdere, som FPM allerede har oprettet.

Se på arbejderens miljø

FPM-puljekonfigurationen leverer clear_env og eksplicitte env[NAME]-poster. Når miljøoprydning er aktiveret, placerer eksport af en variabel i din login-shell den ikke i en arbejder. Puleposter kan videregive udvalgte variabler:

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

Anvend konfigurationsændringer gennem din udrulnings normale FPM-genindlæsningsprocedure. Sæt værdierne i den pulje, der faktisk betjener applikationen. En anden pulje, servicekonto eller container kan forklare, hvorfor en tilsyneladende korrekt redigering ikke har nogen effekt.

Når du fejlretter en live anmodning, skal du kun undersøge, om de forventede indstillinger findes. En offentlig diagnostikside, der udskriver komplette miljøværdier, kan afsløre proxy-legitimationsoplysninger sammen med urelaterede hemmeligheder.

Kontroller derefter PHP-transporten

libcurl har dokumenteret håndtering af proxy-miljø; et eksplicit PHP cURL-håndtag har også sine egne indstillinger. PHP's HTTP-streamomsholder har en separat kontekstkonfiguration. At give variabler til en arbejder får ikke alle PHP-netværks-API'er til at forbruge dem.

Det giver en nyttig kontrol i to dele: bekræft, hvad arbejderen modtog, og bekræft derefter, hvordan den valgte HTTP-klient læser proxyindstillinger. Hvis CLI og FPM modtager de samme værdier, men stadig opfører sig forskelligt, skal du derefter sammenligne klientens indstillinger og omgåelsesregler. Gentagen redigering af shell-profilen kan ikke løse en forskel inde i arbejderens HTTP-klient.