systemd サービスにシェルのプロキシ設定が反映されない理由

端末で変数を追加して export する前に、失敗しているサービスを調べてください。systemctl cat example.service でユニットとドロップインを確認し、EnvironmentFile、ほかの上書き設定、アプリケーション独自のプロキシ設定がないかを調べます。認証情報を含む出力はローカルで確認してください。

アプリケーションが HTTP プロキシの環境変数を利用する場合、サービスのドロップインで次のように指定できます。

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

ドキュメント用の接続先を置き換え、アプリケーションが対応する変数名を使ってください。公開 HTTP プロキシの使用が許可されているサービスなら、候補のアドレスは HTTP プロキシ一覧にあります。独自の設定を持つクライアントは、これらの値を無視することがあります。また、対象が意図したシステムサービスかを確認してください。ユーザーサービスはマネージャーも環境も異なるため、似た名前のシステムユニットを変更しても直りません。

対象のユニットまたはドロップインを編集したら、定義を再読み込みし、処理を中断できるタイミングでそのサービスを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload だけでは、実行中のプロセスの環境は置き換わりません。新しいプロセスを開始するのは再起動です。シェルでの export が影響するのは、そのシェルと、その後にそのシェルが起動する子プロセスだけです。

サービスが想定した URL を受け取ったら、実際のエラーに沿って調べます。そのアカウントには CA ファイルへのアクセス権がない場合があり、ネットワーク名前空間からリスナーに到達できない場合や、プロキシがリクエストを拒否する場合もあります。これらは次の確認事項であり、無関係なシェルのプロファイルを編集し続ける理由ではありません。