Waarom PHP-FPM de proxy verliest die in je terminal werkt

Hetzelfde PHP-bestand kan in een terminal een proxy gebruiken en rechtstreeks verbinden wanneer PHP-FPM het serveert. Begin met de processen te vergelijken die het uitvoeren. Je terminal start PHP met de shellomgeving; de webserver stuurt een verzoek naar workers die FPM al heeft aangemaakt.

Kijk naar de omgeving van de worker

De FPM-poolconfiguratie biedt clear_env en expliciete env[NAME]-vermeldingen. Met omgevingsopschoning ingeschakeld plaatst het exporteren van een variabele in je login-shell die niet in een worker. Poolvermeldingen kunnen geselecteerde variabelen doorgeven:

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

Pas configuratiewijzigingen toe via de gebruikelijke FPM-herlaadprocedure van je deployment. Zet de waarden in de pool die de applicatie daadwerkelijk bedient. Een andere pool, serviceaccount of container kan verklaren waarom een ogenschijnlijk correcte wijziging geen effect heeft.

Controleer bij het debuggen van een live verzoek alleen of de verwachte instellingen bestaan. Een openbare diagnostiekpagina die volledige omgevingswaarden afdrukt, kan proxyreferenties samen met ongerelateerde geheimen blootleggen.

Controleer daarna het PHP-transport

libcurl heeft gedocumenteerde omgevingsafhandeling voor proxies; een expliciete PHP cURL-handle heeft ook eigen opties. De HTTP-streamwrapper van PHP heeft een aparte contextconfiguratie. Variabelen aan een worker geven betekent niet dat elke netwerk-API van PHP ze gebruikt.

Dat geeft een nuttige tweedelige controle: bevestig wat de worker heeft ontvangen en bevestig daarna hoe de gekozen HTTP-client proxy-instellingen leest. Als CLI en FPM dezelfde waarden ontvangen maar zich toch anders gedragen, vergelijk dan als volgende de clientopties en bypass-regels. Herhaald bewerken van het shellprofiel lost een verschil binnen de HTTP-client van de worker niet op.