プロキシ経由でしか外に出られないサーバーで更新やダウンロードを通す設定

社内ネットワークや閉域環境では、サーバーからインターネットへの直接通信が禁止されており、プロキシサーバーを経由しないと外部にアクセスできない構成がよくあります。このような環境でパッケージを更新しようとすると「接続できない」「タイムアウト」といったエラーが出てしまいます。

原因の多くは「どのツールがどこでプロキシ設定を読むか」を把握できていないことです。シェルの環境変数を設定しただけでは、systemd が管理するサービスには反映されません。パッケージマネージャーも独自の設定ファイルを持っています。この記事では、設定を置く場所ごとに整理して解説します。

プロキシ設定の「置き場所」が複数ある理由

Linux のプロセスは、起動した主体によって環境変数の継承元が変わります。ログインシェルから手動で実行したコマンド、systemd が自動起動したサービス、sudo 経由で動くコマンドはそれぞれ異なる経路で環境変数を受け取ります。

そのため「どこに設定するか」は「何をプロキシに通したいか」によって変わります。主な設定先は以下の3か所です。

• システム全体の環境変数（/etc/environment・/etc/profile.d/）
• パッケージマネージャー専用の設定（apt・dnf）
• systemd サービスへの環境変数注入

それぞれ独立して機能するため、サーバー全体でプロキシを通したい場合は3か所すべてを設定しておくのが確実です。

システム全体の環境変数として設定する

/etc/environment は PAM が読み込むファイルで、ログイン時にすべてのユーザーへ適用されます。シェルの種類を問わず動作するため、まずここに設定しておくのが基本です。

HTTP_PROXY=http://proxy.example.local:3128
HTTPS_PROXY=http://proxy.example.local:3128
NO_PROXY=localhost,127.0.0.1,10.0.0.0/8
http_proxy=http://proxy.example.local:3128
https_proxy=http://proxy.example.local:3128
no_proxy=localhost,127.0.0.1,10.0.0.0/8

大文字と小文字の両方を書くのは、ツールによって参照する変数名が異なるためです。curl は小文字を優先しますが、一部のツールは大文字しか見ません。両方書いておくと抜けが起きにくくなります。

NO_PROXY には、プロキシを経由させたくないアドレスを列挙します。社内サーバーのアドレス帯やローカルホストは必ず除外しておきます。

ログインシェル向けには /etc/profile.d/ 以下にスクリプトを置く方法もあります。こちらは export を付ける必要があります。

# /etc/profile.d/proxy.sh
export HTTP_PROXY=http://proxy.example.local:3128
export HTTPS_PROXY=http://proxy.example.local:3128
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8
export http_proxy=http://proxy.example.local:3128
export https_proxy=http://proxy.example.local:3128
export no_proxy=localhost,127.0.0.1,10.0.0.0/8

/etc/environment と /etc/profile.d/ は読まれる経路が異なります（前者は PAM、後者はシェル）。両方に書いておくと、より多くの起動経路をカバーできます。

パッケージマネージャーに個別設定する（apt / dnf）

apt や dnf は sudo 経由で実行されることがほとんどです。sudo はデフォルトで環境変数の一部をリセットするため、/etc/environment の内容が引き継がれないことがあります。パッケージマネージャー専用の設定ファイルを用意しておくと、環境変数の有無にかかわらず確実に動作します。

Debian / Ubuntu（apt）

/etc/apt/apt.conf.d/01proxy というファイルを新規作成し、以下の内容を書きます。

Acquire::http::Proxy "http://proxy.example.local:3128";
Acquire::https::Proxy "http://proxy.example.local:3128";

RHEL 系（dnf / yum）

/etc/dnf/dnf.conf（yum の場合は /etc/yum.conf）の [main] セクションに追記します。

[main]
# 既存の設定の下に追記
proxy=http://proxy.example.local:3128

systemd サービスにプロキシを反映させる

systemd が管理するサービス（docker・containerd・各種デーモンなど）は、/etc/environment の内容を自動では引き継ぎません。ここが最もはまりやすい点です。「シェルからの curl は通るのにサービスからの通信が通らない」という状況はたいていこれが原因です。

すべての systemd サービスに一括で適用するには、/etc/systemd/system.conf の [Manager] セクションに DefaultEnvironment を追記します。

[Manager]
DefaultEnvironment="HTTP_PROXY=http://proxy.example.local:3128" "HTTPS_PROXY=http://proxy.example.local:3128" "NO_PROXY=localhost,127.0.0.1,10.0.0.0/8"

設定後は daemon-reload ではなく daemon-reexec を実行します。daemon-reload はユニットファイルの再読み込みですが、daemon-reexec は systemd プロセス自体を再実行するため、system.conf の変更に必要です。

sudo systemctl daemon-reexec

一括適用ではなく特定サービスだけに適用したい場合は、ドロップインファイルを使います。docker を例にすると次のようになります。

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo tee /etc/systemd/system/docker.service.d/proxy.conf << 'EOF'
[Service]
Environment="HTTP_PROXY=http://proxy.example.local:3128"
Environment="HTTPS_PROXY=http://proxy.example.local:3128"
Environment="NO_PROXY=localhost,127.0.0.1"
EOF
sudo systemctl daemon-reload
sudo systemctl restart docker

設定が効いているか確認する

ログアウト・ログインし直した後、次のコマンドで環境変数が読み込まれているか確認できます。

env | grep -i proxy

実際に外部へ通信が通るかどうかは curl で確かめられます。-v オプションをつけると、プロキシ経由であれば CONNECT や proxy を含む行が出力されます。

curl -v https://example.com 2>&1 | grep -E "Connected|proxy|CONNECT"

パッケージマネージャーが通るかどうかは、パッケージリストの更新コマンドで確認できます。

# Debian/Ubuntu
sudo apt update

# RHEL系
sudo dnf check-update

よくあるつまずきと対処

環境変数を設定したのに sudo apt update が通らない

sudo はセキュリティ上の理由から、デフォルトで呼び出し元の環境変数を引き継がない設定になっています。env | grep proxy で変数が見えていても、sudo 経由の apt には届いていないケースがよくあります。/etc/apt/apt.conf.d/ にプロキシ設定を書いておくと、この問題を回避できます。

daemon-reload しても systemd サービスに反映されない

/etc/systemd/system.conf への変更は、daemon-reload だけでは反映されません。daemon-reexec で systemd プロセス自体を再実行する必要があります。また、すでに起動中のサービスは再起動しないと新しい環境変数を受け取れません。変更後は対象サービスの再起動も忘れずに行います。

HTTPS の通信だけが通らない

プロキシサーバーの種類によっては、HTTPS_PROXY の値も http:// スキームで指定する必要があります。https://proxy... と書くと、プロキシ自体への接続を TLS でラップすると解釈されてしまい、通信に失敗するケースがあります。一般的には http:// で統一しておくのが無難です。

NO_PROXY の範囲が足りずに社内通信が失敗する

社内 DNS・内部 API サーバー・プライベート IP アドレス帯が NO_PROXY に含まれていないと、それらへのアクセスもプロキシ経由になって失敗することがあります。CIDR 記法（10.0.0.0/8）に対応していないツールもあるため、対象アドレスを個別に列挙する方が確実です。また、ドメイン名でアクセスする場合はドメイン自体も NO_PROXY に加えておきます。