Perché PHP-FPM perde il proxy che funziona nel tuo terminale

Lo stesso file PHP può usare un proxy in un terminale e andare diretto quando è servito da PHP-FPM. Inizia confrontando i processi che lo eseguono. Il terminale avvia PHP con l'ambiente della sua shell; il server web invia una richiesta a worker che FPM ha già creato.

Guarda l'ambiente del worker

La configurazione del pool FPM fornisce clear_env e voci env[NAME] esplicite. Con la pulizia dell'ambiente attiva, esportare una variabile nella shell di login non la colloca in un worker. Le voci del pool possono passare variabili selezionate:

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

Applica le modifiche di configurazione tramite la normale procedura di ricarica FPM del tuo deployment. Metti i valori nel pool che serve davvero l'applicazione. Un pool, un account di servizio o un container diverso può spiegare perché una modifica apparentemente corretta non ha effetto.

Durante il debug di una richiesta live, controlla solo se esistono le impostazioni attese. Una pagina di diagnostica pubblica che stampa i valori completi dell'ambiente può esporre credenziali del proxy e segreti non correlati.

Poi controlla il trasporto PHP

libcurl ha una gestione documentata dell'ambiente proxy; anche un handle cURL PHP esplicito ha le proprie opzioni. Il wrapper di stream HTTP di PHP ha una configurazione di contesto separata. Fornire variabili a un worker non fa sì che ogni API di rete PHP le consumi.

Questo offre un'utile verifica in due parti: conferma cosa ha ricevuto il worker, poi conferma come il client HTTP scelto legge le impostazioni del proxy. Se CLI e FPM ricevono gli stessi valori ma si comportano ancora diversamente, confronta poi le opzioni del client e le regole di bypass. Modificare ripetutamente il profilo della shell non può risolvere una differenza dentro il client HTTP del worker.