Linuxのプロキシ設定を確認する時は、まず「どのユーザーの、どのアプリの通信か」を決めます。端末の環境変数、curl、APT、ブラウザー、systemdサービスは同じ設定を必ず使うわけではありません。環境変数が見つかったことと、目的の通信が実際にプロキシを通ったことを分けて確認しましょう。
最初に確認する場所と、確認できる範囲
| 調べたい対象 | 確認する場所 | それだけでは分からないこと |
|---|---|---|
| 現在の端末から実行するコマンド | その端末のhttp_proxy/https_proxy/all_proxy/no_proxy等 | 他ユーザー、起動済みアプリ、サービスの設定 |
| curlの通信 | 環境変数・curlのオプション・curlrc、実際の接続結果 | APTやブラウザーの経路 |
| Ubuntu/DebianのAPT | apt-config dump、AcquireのProxy/ホスト別設定/自動検出 | 環境変数だけを使う別アプリの設定 |
| ログイン時の環境 | /etc/environment、利用シェルの起動ファイル | すべてのサービスへの自動適用 |
| GUIアプリ・サービス | そのアプリ/サービスの公式設定 | 端末の設定との一致 |
1．環境変数の存在を、値を公開せず確認する
Bashの端末で次を実行すると、よく使われる変数について環境へ渡されている名前の有無だけを表示します。setは変数が存在するという意味で、空文字である可能性もあります。URL、ポート、除外先の正しさや、通信の成功まで示す結果ではありません。
for proxy_name in http_proxy HTTP_PROXY https_proxy HTTPS_PROXY ftp_proxy FTP_PROXY all_proxy ALL_PROXY no_proxy NO_PROXY; do
if printenv "$proxy_name" >/dev/null; then
printf "%s=set\n" "$proxy_name"
else
printf "%s=unset\n" "$proxy_name"
fi
done実際の値を調べる場合は、手元で設定ファイルや変数を確認してください。ユーザー名やパスワード入りのプロキシURLがあるため、envの出力や画面全体をそのまま相談先へ送らないようにします。未設定でも、アプリ固有設定や自動設定が使われる可能性があります。
curlの公式説明では、http_proxyは小文字だけを受け付けます。HTTPS_PROXYなど他のプロトコル変数には大文字も使えます。個別のプロトコル変数がALL_PROXYより優先し、no_proxy/NO_PROXYは対象ホストを除外します。この規則を全Linuxアプリ共通と扱わず、使うツールの仕様を確認してください。
2．curlで実際にプロキシを使ったか確認する
まずcurl –versionで版を確認します。curl 8.7.0以降なら、公式のproxy_used出力で、その転送がプロキシを使用した時は1、使用しなかった時は0を確認できます。次はcurlrcを読み込まず、現在の環境変数を使ってHTTPSのヘッダーを取得する確認例です。URLは組織でアクセスが認められた確認先へ変更してください。
curl --version
curl -q --head --connect-timeout 10 --max-time 30 \
--write-out '\nproxy_used=%{proxy_used} http_code=%{http_code}\n' \
https://example.com/この例の-qは最初のオプションで、curlrcの影響を除くためです。普段のcurlがcurlrcのproxy設定を使う場合は、その設定を別途照合します。proxy_used=1でも認証、TLS、目的のサイトへのアクセスが成功したとは限りません。エラーとHTTPの結果も確認してください。古いcurlで変数が未対応ならこの書式を使わず、–verboseの接続先やCONNECTの結果を手元で確認します。詳細ログにも機密情報が含まれることがあります。
3．設定ファイルは、読む条件も確認する
/etc/environment：PAMを使うログイン環境
cat /etc/environmentpam_envの仕様では/etc/environmentはKEY=VALUEを行ごとに記載するファイルです。読み込みはPAMの設定と呼び出し条件によるため、編集すれば全プロセスや全systemdサービスへ即時適用されるという意味ではありません。閲覧結果に認証情報があれば公開しないでください。
/etc/profile・~/.bashrc：Bashの起動方法で違う
cat /etc/profileGNU Bashの起動仕様では、対話ログインシェルは/etc/profileと、~/.bash_profile、~/.bash_login、~/.profileのうち最初に読めるものを読みます。対話非ログインシェルは~/.bashrcを読みます。/etc/profileだけを見てもユーザー側の設定は分からず、Bash以外のシェルには別の設定があります。
4．APTはapt.confだけでなく、読み込まれた設定を確認する
Ubuntu/DebianでAPTを調べる場合は、APT_CONFIGや/etc/apt/apt.conf.d内のファイル、/etc/apt/apt.conf等を考慮します。APTの読み込み順では設定断片、メイン設定、コマンドライン等で上書きされるため、1ファイルへのgrepだけでは不足します。次の結果は設定値を含むため手元で確認してください。
apt-config dump | grep -i 'Acquire::.*Proxy'apt-config dumpはAPTの設定空間を表示します。APTのProxy仕様に従ってAcquire::http::Proxy、Proxy::ホスト名、Proxy-Auto-Detect、DIRECTも確認してください。空の結果でもhttp_proxy環境変数などを利用する場合があり、自動検出の設定が出ても、その時の検出結果までdumpで分かるわけではありません。sudoで実行するAPTと一般ユーザーの端末では環境が異なる場合もあります。
設定する場合：一時設定から試す
アドレスとポートは管理者が案内する値を使用します。次は認証なしHTTPプロキシを利用する例で、現在のシェルと、そこから新しく起動する環境変数対応のコマンドに適用します。https_proxyという名前でも、接続先のプロキシがHTTPなら値はhttp://です。
export http_proxy="http://proxy.example:8080"
export https_proxy="http://proxy.example:8080"
export no_proxy="localhost,127.0.0.1,.internal.example"curlでは.internal.exampleのような先頭ドット付きの除外指定はそのドメインに一致します。除外規則の解釈はツールごとに確認し、社内ネットワークを通す必要がある通信を根拠なく除外しないでください。ftp_proxyはFTPを使い、そのプロキシが対応する場合にだけ追加します。
Bashで継続して使う場合
対話非ログインのBashで使うなら、~/.bashrcをエディターで確認し、既存の同じ変数を整理して次の内容を記載します。同じ行を毎回追記する必要はありません。ログインシェル側からこのファイルを読む構成かも確認します。
# ~/.bashrcに記載する内容の例
export http_proxy="http://proxy.example:8080"
export https_proxy="http://proxy.example:8080"
export no_proxy="localhost,127.0.0.1,.internal.example"自分で内容を確認した~/.bashrcを編集後、現在のBashにも反映する場合は次を使えます。sourceはファイル全体を実行するため、他の処理も実行されます。すでに動いている別アプリやサービスへ反映する操作ではありません。
source ~/.bashrc/etc/environmentを編集する場合
必要性とPAMの読み込み条件を確認したうえで、既存内容を保存し、管理権限のあるエディターで対象行を編集します。下はファイルへ記載する内容で、端末へ貼って全体設定を変更するコマンドではありません。exportやシェルの変数展開を前提にしないでください。
# /etc/environmentへ記載する内容の例
http_proxy="http://proxy.example:8080"
https_proxy="http://proxy.example:8080"
no_proxy="localhost,127.0.0.1,.internal.example"sudo echo … >> /etc/environmentという形は避けます。Bashのリダイレクト仕様では、>>の処理はコマンドより前に呼び出し元のシェルが行います。echoだけをsudoで動かしても、その書き込みに管理権限が付くわけではありません。編集後は対象のログイン環境で読み直されたかを確認します。
APT専用の設定を記載する場合
APTの利用が目的なら、既存のProxy設定と上書き順を確認し、管理権限のあるエディターで/etc/apt/apt.conf.d/80proxyなどの適切な設定断片へ記載します。次のコマンドは記載例の2行を画面へ出すだけで、ファイルには書き込みません。APT設定の行そのものはBashコマンドではありません。
printf '%s\n' \
'Acquire::http::Proxy "http://proxy.example:8080/";' \
'Acquire::https::Proxy "http://proxy.example:8080/";'APTのHTTPS設定も確認し、保存後はapt-config dumpの結果を再確認します。/etc/apt/apt.confなど後から読む場所の設定に上書きされていないかが要点です。認証が必要なら、パスワードを広く読めるapt.confへ直接記載せず、apt_auth.confの制限付きファイルを管理者の方針に従って利用してください。
接続できない時：プロキシ指定と除外設定を切り分ける
次は確認先に対してプロキシを明示し、no_proxyの除外だけをこのcurl実行で無効にする例です。利用が認められたプロキシと確認先へ変更して使います。pingやTCP接続の成功だけでは、HTTPプロキシの認証やHTTPS接続まで確認できません。
curl -q --proxy http://proxy.example:8080 --noproxy '' \
--head --connect-timeout 10 --max-time 30 https://example.com/| 観測した結果 | 次の確認 |
|---|---|
| 環境変数があるのにcurlでproxy_used=0 | 対象ホストのno_proxy、変数の大文字/小文字、空値、別プロトコル指定 |
| プロキシを明示した時だけ接続できる | 普段の環境変数、curlrc、除外先と実行ユーザーを比較 |
| 名前解決/接続/タイムアウトで失敗 | プロキシの実アドレス、ポート、経路とその時刻のログ |
| プロキシ認証のエラー | 要求された認証方式とアカウント、管理者の公式設定 |
| TLS証明書のエラー | 対象サイトとプロキシ、組織のCAの適切な登録。検証無効化で済ませない |
| curlは成功、APTやGUIだけ失敗 | そのアプリの設定、実行ユーザー、対象URL、プロキシ側の許可を照合 |
systemdサービスの環境はUnitのEnvironment/EnvironmentFile等から組み立てられます。端末でexportした値がすべてのシステムサービスへ渡ると考えず、対象サービスの公式設定を調べてください。ブラウザーも自身の手動設定、自動設定、管理ポリシー等の実際の設定を確認します。
設定の確認は、変数の名前、設定ファイルの内容、実際の通信経路という順で進めます。どのアプリがどのユーザーで何へ接続する時に失敗するのかと、変更前後の結果を残すと、設定の食い違いを特定しやすくなります。
コメント