Kvifor PHP-FPM mistar proxyen som verkar i terminalen

Den same PHP-fila kan bruke ein proxy i ein terminal og gå direkte når PHP-FPM tener ho. Byrje med å samanlikne prosessane som køyrer ho. Terminalen startar PHP med skalemiljøet; nettenaren sender ein førespurnad til arbeidarar som FPM allereie har oppretta.

Sjå på miljøet til arbeidaren

FPM-bassengkonfigurasjonen gir clear_env og eksplisitte env[NAME]-oppføringar. Med miljørydding påslått plasserer ikkje eksport av ein variabel i innloggingsskalet han i ein arbeidar. Bassengoppføringar kan senda vidare utvalde variablar:

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

Bruk konfigurasjonsendringar gjennom den vanlege FPM-omlastingsprosedyren i utrullinga. Set verdiane i bassenger som faktisk tener applikasjonen. Eit anna basseng, tenestekonto eller container kan forklare kvifor ei tilsynelatande rett endring ikkje har effekt.

Når du feilsøkjer ein aktiv førespurnad, kontroller berre om dei forventa innstillingane finst. Ei offentleg diagnoseside som skriv ut komplette miljøverdiar kan avdekkje proxy-legitimasjon saman med urelaterte løyndomar.

Sjekk deretter PHP-transporten

libcurl har dokumentert handtering av proxy-miljø; eit eksplisitt PHP cURL-handtak har også eigne val. HTTP-straumeinnpakninga til PHP har ein eigen kontekstkonfigurasjon. Å gje variablar til ein arbeidar gjer ikkje at alle nettverks-API-ane til PHP brukar dei.

Det gir ein nyttig todelt sjekk: stadfest kva arbeidaren fekk, og stadfest deretter korleis den valde HTTP-klienten les proxyinnstillingar. Viss CLI og FPM får dei same verdiane men framleis oppfører seg ulikt, samanlikn klientval og omgåingsreglar neste gong. Gjenteken redigering av skaleprofilen kan ikkje avgjere ein skilnad inne i HTTP-klienten til arbeidaren.