Por qué un servicio systemd no recibe la configuración proxy de tu shell

Inspecciona el servicio que falla en vez de exportar otra variable en el terminal. systemctl cat example.service muestra su unidad y sus archivos complementarios; busca un EnvironmentFile, otra sobrescritura o ajustes proxy propios de la aplicación. Lee localmente la salida que contenga credenciales.

Si la aplicación utiliza variables de entorno de proxy HTTP, un archivo complementario del servicio puede proporcionar:

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

Sustituye el destino de ejemplo y usa los nombres de variable admitidos por la aplicación. Si el servicio tiene permiso para usar proxies HTTP públicos, puedes encontrar direcciones candidatas en la lista de proxies HTTP. Un cliente con configuración propia puede ignorar estas entradas. Confirma también que se trata del servicio de sistema previsto: un servicio de usuario tiene un gestor y un entorno distintos; cambiar una unidad de sistema con un nombre parecido no lo arreglará.

Tras editar la unidad o el archivo complementario correspondiente, recarga las definiciones y reinicia ese servicio cuando pueda interrumpirse su carga de trabajo:

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload por sí solo no sustituye el entorno de un proceso en ejecución. El reinicio inicia el nuevo proceso; un export en el shell afecta solo a ese shell y a los procesos hijos que inicie después.

Una vez que el servicio recibe la URL esperada, sigue el error que realmente presenta. Su cuenta puede no tener acceso al archivo CA, su espacio de nombres de red puede no alcanzar el punto de escucha o el proxy puede rechazar la solicitud. Son comprobaciones posteriores, no motivos para seguir editando perfiles de shell ajenos al problema.