Por que o PHP-FPM perde o proxy que funciona no seu terminal

O mesmo arquivo PHP pode usar um proxy em um terminal e conectar-se diretamente quando servido pelo PHP-FPM. Comece comparando os processos que o executam. Seu terminal inicia o PHP com o ambiente do shell; o servidor web envia uma requisição a workers que o FPM já criou.

Observe o ambiente do worker

A configuração do pool FPM fornece clear_env e entradas explícitas env[NAME]. Com a limpeza de ambiente ativada, exportar uma variável no shell de login não a coloca em um worker. Entradas do pool podem passar variáveis selecionadas:

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

Aplique alterações de configuração pelo procedimento normal de recarga do FPM da sua implantação. Coloque os valores no pool que realmente atende a aplicação. Um pool, conta de serviço ou contêiner diferente pode explicar por que uma edição aparentemente correta não tem efeito.

Ao depurar uma requisição ativa, inspecione apenas se as configurações esperadas existem. Uma página pública de diagnóstico que imprime valores completos de ambiente pode expor credenciais de proxy junto com segredos não relacionados.

Depois verifique o transporte do PHP

O libcurl tem tratamento documentado de ambiente de proxy; um identificador PHP cURL explícito também tem suas próprias opções. O wrapper de stream HTTP do PHP tem uma configuração de contexto separada. Fornecer variáveis a um worker não faz com que toda API de rede do PHP as consuma.

Isso oferece uma verificação útil em duas partes: confirme o que o worker recebeu e depois confirme como o cliente HTTP escolhido lê as configurações de proxy. Se CLI e FPM recebem os mesmos valores mas ainda se comportam de forma diferente, compare em seguida as opções do cliente e as regras de bypass. Editar repetidamente o perfil do shell não resolve uma diferença dentro do cliente HTTP do worker.