Hvorfor PHP-FPM mister proxyen som fungerer i terminalen

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

Se på miljøet til arbeideren

FPM-pool-konfigurasjonen tilbyr clear_env og eksplisitte env[NAME]-oppføringer. Når miljørydding er slått på, plasserer ikke eksport av en variabel i innloggingsskallet den i en arbeider. Pooloppføringer kan sende videre utvalgte variabler:

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

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

Når du feilsøker en levende forespørsel, sjekk bare om de forventede innstillingene finnes. En offentlig diagnoseside som skriver ut komplette miljøverdier kan avsløre 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 alternativer. PHPs HTTP-strøm-wrapper har en egen 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 klientalternativer og omgåelsesregler neste gang. Gjentatt redigering av skallprofilen kan ikke avgjøre en forskjell inne i arbeiderens HTTP-klient.