Varför PHP-FPM tappar proxyn som fungerar i terminalen

Samma PHP-fil kan använda en proxy i en terminal och gå direkt när PHP-FPM serverar den. Börja med att jämföra processerna som kör den. Terminalen startar PHP med skalets miljö; webbservern skickar en begäran till arbetare som FPM redan har skapat.

Titta på arbetarens miljö

FPM-poolkonfigurationen tillhandahåller clear_env och explicita env[NAME]-poster. Med miljörensning aktiverad placerar en export av en variabel i inloggningsskalet den inte i en arbetare. Poolposter kan skicka vidare valda variabler:

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

Tillämpa konfigurationsändringar genom distributionens vanliga FPM-omladdningsförfarande. Lägg värdena i poolen som faktiskt betjänar applikationen. En annan pool, tjänstekonto eller container kan förklara varför en till synes korrekt ändring inte har någon effekt.

När du felsöker en aktiv begäran, kontrollera bara om de förväntade inställningarna finns. En offentlig diagnostiksida som skriver ut fullständiga miljövärden kan exponera proxyuppgifter tillsammans med orelaterade hemligheter.

Kontrollera sedan PHP-transporten

libcurl har dokumenterad hantering av proxymiljö; ett explicit PHP cURL-handtag har också egna alternativ. PHP:s HTTP-strömomslag har en separat kontextkonfiguration. Att ge variabler till en arbetare gör inte att varje PHP-nätverks-API använder dem.

Det ger en användbar tvådelad kontroll: bekräfta vad arbetaren tog emot och bekräfta sedan hur den valda HTTP-klienten läser proxyinställningar. Om CLI och FPM tar emot samma värden men fortfarande beter sig olika, jämför sedan klientalternativ och undantagsregler. Upprepad redigering av skalprofilen kan inte lösa en skillnad inuti arbetarens HTTP-klient.