Por que um serviço systemd não recebe as configurações de proxy do shell

Inspecione o serviço que falha em vez de exportar outra variável no terminal. systemctl cat example.service mostra a unidade e seus arquivos complementares; procure um EnvironmentFile, outra sobrescrita ou configurações de proxy da própria aplicação. Leia localmente saídas que contenham credenciais.

Se a aplicação usa variáveis de ambiente de proxy HTTP, um arquivo complementar do serviço pode fornecer:

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

Substitua o endpoint de exemplo e use os nomes de variável aceitos pela aplicação. Para um serviço autorizado a usar proxies HTTP públicos, há endereços candidatos na lista de proxies HTTP. Um cliente com configuração própria pode ignorar essas entradas. Confirme também que esse é o serviço de sistema pretendido: um serviço de usuário tem outro gerenciador e outro ambiente; alterar uma unidade de sistema com nome parecido não vai corrigi-lo.

Depois de editar a unidade ou o arquivo complementar correto, recarregue as definições e reinicie esse serviço quando sua carga de trabalho puder ser interrompida:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload sozinho não substitui o ambiente de um processo em execução. O reinício inicia o novo processo; um export no shell afeta somente esse shell e os processos filhos que ele iniciar depois.

Quando o serviço receber a URL esperada, siga o erro real. A conta usada pode não ter acesso ao arquivo CA, o namespace de rede pode não alcançar o listener ou o proxy pode rejeitar a solicitação. Essas são verificações posteriores, não motivos para continuar editando perfis de shell sem relação com o problema.