Hvorfor PHP-FPM mister proxyen som virker i terminalen

Den samme PHP-filen kan bruke en proxy i en terminal og gå direkte når PHP-FPM serverer den. Begynn med å sammenligne prosessene som kjører den. Terminalen starter PHP med skallmiljøet; nettjeneren sender en forespørsel til arbeidere som FPM allerede har opprettet.

Se på arbeiderens miljø

FPM-poolkonfigurasjonen gir clear_env og eksplisitte env[NAME]-oppføringer. Med miljøopprydding aktivert plasserer ikke eksport av en variabel i innloggingsskallet den i en arbeider. Pooloppføringer kan gi videre utvalgte variabler:

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

Bruk konfigurasjonsendringer gjennom utrullingens vanlige FPM-omlastingsprosedyre. Sett verdiene i poolen som faktisk betjener applikasjonen. En annen pool, tjenestekonto eller beholder kan forklare hvorfor en tilsynelatende riktig endring ikke har effekt.

Når du feilsøker en aktiv forespørsel, kontroller bare om de forventede innstillingene finnes. En offentlig diagnoseside som skriver ut komplette miljøverdier kan eksponere proxy-legitimasjon sammen med urelaterte hemmeligheter.

Sjekk deretter PHP-transporten

libcurl har dokumentert håndtering av proxy-miljø; et eksplisitt PHP cURL-håndtak har også egne valg. PHPs HTTP-strøm-wrapper har en separat kontekstkonfigurasjon. Å gi variabler til en arbeider gjør ikke at alle PHPs nettverks-API-er bruker dem.

Det gir en nyttig todelt sjekk: bekreft hva arbeideren mottok, og bekreft deretter hvordan den valgte HTTP-klienten leser proxyinnstillinger. Hvis CLI og FPM mottar de samme verdiene men fortsatt oppfører seg ulikt, sammenlign klientvalg og omgåelsesregler neste gang. Gjentatt redigering av skallprofilen kan ikke avgjøre en forskjell inne i arbeiderens HTTP-klient.