プロキシの例外設定について

プロキシの例外設定とは、特定の宛先にアクセスするときだけ、プロキシサーバーを経由せずに直接通信させるための設定です。

プロキシを利用している環境では、通常、Webサイトや外部サービスへの通信がプロキシサーバーを経由します。

しかし、社内システム、ローカル開発環境、社内IPアドレス、特定の業務用サーバーなどは、プロキシを通すことでアクセスできなくなる場合があります。

そのような宛先をあらかじめ例外として登録しておくことで、必要な通信だけを直接接続できます。

たとえば、外部サイトへのアクセスはプロキシを経由し、社内ポータルやローカル開発サーバーへのアクセスは直接接続する、という使い方ができます。

プロキシ例外設定が必要になる理由

社内システムへ正常にアクセスするため

企業ネットワークでは、社内ポータル、勤怠管理システム、ファイルサーバー、社内Git、社内リポジトリなどが、社内ネットワーク内に配置されていることがあります。

これらの宛先は、外部インターネット上に公開されていない場合が多く、プロキシサーバーを経由すると正しく到達できないことがあります。

そのため、社内ドメインや社内サーバー名は、プロキシ例外に設定されることが多いです。

ローカル開発環境に接続するため

Web開発では、自分のPC上で開発サーバーを起動し、ブラウザやアプリケーションから動作確認を行うことがあります。

このようなローカル環境への通信は、本来プロキシを経由する必要がありません。

プロキシを経由してしまうと、ブラウザや開発ツールがローカルサーバーに接続できなくなる場合があります。

そのため、ローカルホストやループバックアドレスは、基本的にプロキシ例外に含めるのが一般的です。

プライベートIPアドレスへの通信を直接行うため

社内LANや家庭内LANでは、プライベートIPアドレスが使われます。

10系、172.16〜172.31系、192.168系のIPアドレスは、社内ネットワークやローカルネットワークでよく使われる範囲です。

これらのアドレスはインターネット上の公開IPではないため、プロキシを通すよりも直接接続した方が自然です。

社内サーバー、プリンター、NAS、開発用サーバーなどにアクセスする場合、これらのIPアドレスを例外に入れることがあります。

プロキシ認証の問題を避けるため

企業プロキシでは、ユーザー認証が必要になることがあります。

ブラウザでは問題なく認証できても、Git、npm、curl、Docker、Javaアプリ、Pythonスクリプトなどの開発ツールでは、プロキシ認証がうまく処理できない場合があります。

特に、社内リポジトリやローカルサービスにアクセスする場合は、プロキシを経由しないように例外設定を行うことで、認証エラーや接続エラーを避けられることがあります。

例外設定に入れることが多い対象

ローカルホスト

ローカルホストは、自分のPC自身を指す宛先です。

開発環境やローカルアプリケーションの確認でよく使われます。

ローカルホストへの通信をプロキシ経由にすると、意図したアプリケーションに接続できないことがあるため、基本的には例外に入れます。

対象としては、localhost、IPv4のループバックアドレス、IPv6のループバックアドレスなどがあります。

社内ドメイン

社内システムが特定の社内ドメイン配下で運用されている場合、そのドメインを例外に入れることがあります。

たとえば、社内ポータル、社内Git、社内パッケージリポジトリ、社内API、社内管理画面などが対象です。

ただし、ドメインの書き方はOSやツールによって異なります。

ワイルドカードを使える環境もあれば、先頭ドットでサブドメインを表す環境もあります。

社内サーバー名

社内では、ドメイン名ではなく短いサーバー名でアクセスすることがあります。

たとえば、intranet、server01、fileserver、printer のような名前です。

このようなドットを含まないローカル名は、プロキシを通すと解決できないことがあるため、例外に入れる対象になります。

プライベートIPアドレス

社内LANや家庭内LANで使うIPアドレスも、例外対象になることがあります。

10系、172.16〜172.31系、192.168系は、プライベートIPアドレスとしてよく使われます。

ただし、IP範囲の指定方法は環境によって異なります。ワイルドカード形式が使える場合もあれば、CIDR表記に対応している場合もあります。

一方で、どちらも期待どおりに動かないツールもあります。

Windowsでのプロキシ例外設定

基本的な考え方

Windowsでは、システムのプロキシ設定に例外リストを入力できます。

Windowsのプロキシ例外では、複数の宛先をセミコロンで区切って指定することが一般的です。

また、ワイルドカードを使ったドメイン指定も利用されることがあります。

ローカルホスト、社内ドメイン、社内IPアドレス、社内サーバー名などを例外として指定します。

注意点

Windowsでプロキシ例外を設定しても、すべてのアプリケーションに必ず反映されるわけではありません。

ChromeやEdgeはWindowsのシステムプロキシ設定を利用することが多いですが、Firefoxや一部の開発ツール、CLIツール、独自の通信ライブラリを使うアプリケーションでは、別のプロキシ設定を参照する場合があります。

そのため、ブラウザではアクセスできるのに、Gitやnpmでは失敗するということもあります。

macOSでのプロキシ例外設定

基本的な考え方

macOSでも、ネットワーク設定からプロキシを使用しないホストやドメインを指定できます。

社内ドメイン、ローカルホスト、特定のサーバー名、特定のIPアドレスなどを例外として登録します。

macOSでは、ドメイン全体を対象にするためにワイルドカードを使うことがあります。

ただし、設定画面やアプリケーションによって解釈が異なる可能性があります。

CIDR表記には注意が必要

macOSのプロキシ例外欄で、IPアドレスの範囲をCIDR表記で指定できるように見える場合があります。

しかし、CIDR表記がすべてのアプリケーションで期待どおりに解釈されるとは限りません。

特に、ブラウザ、ターミナルのツール、開発環境、社内セキュリティソフトなどが絡む場合は、実際に通信テストをして確認することが重要です。

ブラウザごとの違い

ChromeとEdge

ChromeとEdgeは、基本的にOSのプロキシ設定を参照することが多いです。

WindowsであればWindowsのプロキシ設定、macOSであればmacOSのネットワーク設定が利用されます。

ただし、企業管理の端末では、ブラウザポリシーによってプロキシ設定が固定されていることがあります。

その場合、ユーザーがOS側で設定を変更しても反映されないことがあります。

Firefox

Firefoxは、OSのプロキシ設定を使うこともできますが、Firefox独自のプロキシ設定を持つこともできます。

そのため、OS側でプロキシ例外を設定しても、Firefoxが独自設定を使っている場合は反映されません。

Firefoxでは、プロキシを使用しないホストやIPアドレスを専用の欄に指定できます。

また、ドットを含まないローカルホスト名を除外するための指定方法もあります。

社内サーバー名を使う環境では、Firefox側の例外設定も確認した方が安全です。

CLIツールと環境変数のプロキシ例外

NO_PROXYの役割

Git、curl、npm、Python、Node.js、Docker内のアプリケーションなどは、OSのプロキシ設定ではなく、環境変数を参照することがあります。

その場合、プロキシ例外に相当する設定として NO_PROXY または no_proxy が使われます。

NO_PROXY には、プロキシを経由しない宛先をカンマ区切りで指定します。

NO_PROXYは標準化されていない点に注意

NO_PROXYは広く使われていますが、厳密に統一された仕様があるわけではありません。

そのため、同じ指定をしても、curl、Git、npm、Python、Node.js、Docker、各種ライブラリで解釈が異なることがあります。

特に注意すべきなのは、サブドメイン指定、ワイルドカード、CIDR表記です。

あるツールでは有効でも、別のツールでは無視されることがあります。

大文字と小文字の違い

環境変数には、大文字の HTTP_PROXY、HTTPS_PROXY、NO_PROXY と、小文字の http_proxy、https_proxy、no_proxy があります。

ツールによって参照する環境変数が異なる場合があるため、実務では大文字と小文字の両方を設定することがあります。

ただし、環境によっては大文字の HTTP_PROXY がセキュリティ上の理由で扱いに注意されることもあるため、対象ツールの仕様を確認するのが安全です。

ドメイン指定の注意点

ルートドメインとサブドメインは分けて考える

プロキシ例外では、example.co.jp のようなルートドメインと、intranet.example.co.jp のようなサブドメインを分けて考える必要があります。

ある設定では example.co.jp を指定すればサブドメインも含まれることがありますが、別の設定ではルートドメインだけにしか効かないことがあります。

逆に、先頭にドットを付けた指定やワイルドカード指定が、サブドメインには効くもののルートドメイン自体には効かない場合もあります。

ワイルドカードは環境依存

WindowsやmacOSのプロキシ例外では、ワイルドカードを使ったドメイン指定が利用されることがあります。

一方、NO_PROXYでは、ワイルドカードの扱いがツールによって異なります。

そのため、OSのプロキシ例外欄では有効な書き方が、CLIツールでは効かないことがあります。

確実性が必要な場合は対象を明示する

業務上重要なサーバーについては、範囲指定だけに頼らず、対象ホスト名を明示的に登録する方が安全です。

社内Git、社内リポジトリ、社内API、社内ポータルなど、確実にプロキシを通したくない宛先は、個別に指定しておくとトラブルを減らせます。

IPアドレス指定の注意点

ワイルドカード形式

Windowsのプロキシ例外などでは、IPアドレスの一部にワイルドカードを使う指定が使われることがあります。

たとえば、192.168系や10系のIPアドレスをまとめて除外するような指定です。

ただし、この形式がすべてのツールで使えるわけではありません。

CIDR形式

CIDR表記は、IPアドレス範囲を表す一般的な書き方です。

たとえば、10系全体、192.168系全体、172.16〜172.31系をまとめて表すことができます。

しかし、プロキシ例外設定においてCIDR表記を解釈できるかどうかは、ツールやライブラリによって異なります。

特に NO_PROXY では、CIDR表記が効く環境と効かない環境があります。

個別指定が必要な場合もある

CIDRやワイルドカードが効かない場合は、アクセス先のIPアドレスを個別に指定する必要があります。

特に、社内の特定サーバーや業務上重要な機器に接続する場合は、範囲指定よりも個別指定の方が確実なことがあります。

Javaでのプロキシ例外

Javaは独自の指定方法を使う

Javaアプリケーションでは、OSのプロキシ設定やNO_PROXYではなく、JVMのプロパティでプロキシや例外設定を指定することがあります。

Javaでは、プロキシを使用しないホストを指定する設定として http.nonProxyHosts がよく使われます。

区切り文字が違う

Javaの非プロキシホスト指定では、一般的にパイプ記号で複数の対象を区切ります。

これは、Windowsのセミコロン区切りや、NO_PROXYのカンマ区切りとは異なります。

そのため、他の環境の設定をそのままJavaにコピーしても、期待どおりに動かないことがあります。

ワイルドカードが使える

Javaの非プロキシホスト設定では、ワイルドカードを使ったホスト指定が可能です。

ローカルホスト、社内ドメイン、社内IPの一部などを指定することがあります。

ただし、実際の挙動はJavaのバージョンや利用しているHTTPクライアントライブラリ、アプリケーション側の実装にも影響されます。

Dockerでのプロキシ例外

Dockerは設定箇所が複数ある

Dockerでは、プロキシ設定をどこに入れるべきかを分けて考える必要があります。

Docker daemon、Docker CLI、Docker Desktop、コンテナ内アプリケーション、ビルド時の処理など、それぞれ通信主体が異なるためです。

docker pull が失敗する場合

イメージの取得に失敗する場合は、Docker daemon側のプロキシ設定を確認する必要があります。

この場合、コンテナ内の環境変数を設定しても解決しないことがあります。

コンテナ内の通信が失敗する場合

コンテナ内でnpm、curl、apt、pipなどが失敗する場合は、コンテナ内のプロキシ設定やNO_PROXY設定を確認します。

ホストOS側のプロキシ例外を設定していても、それが自動的にコンテナ内へ反映されるとは限りません。

docker build 中に失敗する場合

Docker build中に外部パッケージの取得が失敗する場合は、ビルド時のプロキシ設定を確認する必要があります。

実行時のコンテナ設定と、ビルド時の設定は別物として考えるべきです。

Gitでのプロキシ例外

Gitは複数の設定元に影響される

Gitの通信は、Gitの設定、環境変数、OS設定、利用しているlibcurlなどの影響を受けることがあります。

そのため、OS側でプロキシ例外を設定しても、Gitでは別のプロキシ設定が使われている場合があります。

グローバル設定とリポジトリ単位の設定

Gitでは、全体に適用されるグローバル設定と、特定リポジトリだけに適用されるローカル設定があります。

社内Gitだけプロキシを通したくない場合や、特定リポジトリだけ設定を変えたい場合は、どのスコープで設定するかを確認する必要があります。

設定元の確認が重要

Gitでプロキシ関連のトラブルが起きた場合は、どこでプロキシが設定されているかを確認することが重要です。

グローバル設定、ローカル設定、環境変数、会社配布の設定などが競合していることがあります。

npmでのプロキシ例外

npmはproxyとhttps-proxyを持つ

npmでは、プロキシサーバーを指定するための設定があります。

通常のHTTP通信とHTTPS通信で、それぞれプロキシ設定を持つことがあります。

例外設定は環境依存になりやすい

npmのプロキシ例外は、OSの設定だけでなく、環境変数、npmのバージョン、Node.jsの挙動、内部で使われているライブラリの影響を受けることがあります。

そのため、NO_PROXYを設定しても、必ずすべてのnpm関連通信に期待どおり反映されるとは限りません。

社内リポジトリ利用時は注意

社内npmレジストリやプライベートリポジトリを利用している場合、プロキシ経由にすべき通信と、直接通信にすべき通信が混在することがあります。

この場合は、npmの設定、環境変数、社内ネットワークの名前解決、証明書設定をまとめて確認する必要があります。

PACファイルによるプロキシ例外

PACファイルとは

PACファイルは、アクセス先に応じてプロキシを使うか直接接続するかを自動判定するための設定ファイルです。

企業ネットワークでは、手動でプロキシサーバーを設定する代わりに、PACファイルを配布していることがあります。

柔軟な制御ができる

PACファイルを使うと、社内ドメインは直接接続、外部サイトはプロキシ経由、特定IP範囲は直接接続、といった柔軟な制御ができます。

単純な例外リストよりも細かい条件分岐ができるため、大規模な企業環境ではよく使われます。

書き方によっては遅延や誤判定が起きる

PACファイルでは、ホスト名やIPアドレスの判定を行います。

ただし、IP範囲判定のために名前解決が必要になる場合があり、書き方によっては通信の遅延や意図しない判定が起きることがあります。

そのため、PACファイルはネットワーク管理者が慎重に設計・検証するべき設定です。

プロキシ例外設定が効かない原因

設定する場所が違う

最もよくある原因は、設定している場所と、実際にアプリが参照している場所が違うことです。

OSに設定しても、アプリが独自のプロキシ設定を使っていれば反映されません。

ブラウザ、CLIツール、Docker、Java、Git、npmなどは、それぞれ確認すべき場所が異なります。

区切り文字が違う

プロキシ例外の区切り文字は、環境によって異なります。

Windowsではセミコロン、NO_PROXYではカンマ、Javaではパイプ記号が使われることがあります。

区切り文字を間違えると、複数の例外が1つの長い文字列として扱われ、期待どおりに動かないことがあります。

ワイルドカードの解釈が違う

ワイルドカードの使い方も、環境によって異なります。

ある環境ではサブドメイン全体に効いても、別の環境では無効になることがあります。

特に、OSのプロキシ例外欄とNO_PROXYでは、同じ書き方が通用しない場合があります。

CIDR表記が対応していない

IPアドレス範囲をCIDRで指定しても、ツールが対応していなければ無視されます。

NO_PROXYでCIDRを使う場合は、対象ツールが対応しているかどうかを確認する必要があります。

大文字・小文字の環境変数の違い

一部のツールは大文字の環境変数を見ますが、別のツールは小文字の環境変数を見ます。

そのため、片方だけ設定していると、ツールによってはプロキシ例外が効かないことがあります。

複数の設定が競合している

OS設定、ブラウザ設定、VPNクライアント、セキュリティソフト、環境変数、アプリ固有設定、PACファイルなどが同時に存在すると、どれが実際に使われているのか分かりにくくなります。

この場合は、設定を1つずつ確認し、どの通信にどの設定が効いているのかを切り分ける必要があります。

実務での設定方針

まずローカルホストを例外に入れる

開発環境やローカルアプリケーションを使う場合、ローカルホストは基本的にプロキシ例外に入れるべきです。

これにより、自分のPC上で動いているアプリケーションや開発サーバーへ正常に接続しやすくなります。

次に社内ドメインを追加する

社内システムが特定のドメイン配下にある場合、そのドメインをプロキシ例外に追加します。

ただし、ルートドメインとサブドメインの扱いは環境によって違うため、必要に応じて両方を意識して指定します。

重要な社内サーバーは個別指定する

社内Git、社内パッケージリポジトリ、社内API、認証サーバーなど、業務上重要な宛先は個別に指定した方が安全です。

範囲指定やワイルドカードだけに頼ると、環境によっては期待どおりに除外されないことがあります。

IP範囲指定は検証前提で使う

プライベートIPアドレス全体を例外に入れたい場合、ワイルドカードやCIDR表記を使うことがあります。

ただし、どの書き方が使えるかは環境によって異なります。

特にCLIツールや開発ツールでは、実際に通信確認を行うことが重要です。

セキュリティ上の注意点

例外を広げすぎない

プロキシ例外は便利ですが、広げすぎるとセキュリティ上のリスクになります。

プロキシは、アクセス制御、ログ取得、マルウェア対策、フィルタリング、監査などの役割を持つことがあります。

本来プロキシを通すべき外部通信まで例外にしてしまうと、組織のセキュリティポリシーを回避する形になってしまう可能性があります。

外部サービスを安易に例外にしない

Google、GitHub、AWS、Cloudflareなどの外部サービスを広範囲に例外へ入れるのは慎重に考えるべきです。

業務上どうしても必要な場合でも、会社のネットワーク管理者やセキュリティ担当者に確認するのが安全です。

すべてを直接接続にする設定は避ける

すべての通信をプロキシ例外にするような設定は、実質的にプロキシを無効化することになります。

一時的な切り分けとして使う場合はありますが、恒久的な設定としては避けるべきです。

まとめ

プロキシの例外設定は、特定の宛先に対してプロキシを使わず、直接アクセスするための設定です。

社内システム、ローカル開発環境、社内サーバー、プライベートIPアドレスなどにアクセスする場合によく使われます。

ただし、プロキシ例外の書き方は環境によって大きく異なります。

Windowsではセミコロン区切りやワイルドカードが使われることが多く、macOSではネットワーク設定上の例外欄を利用します。

CLIツールではNO_PROXYが使われますが、ワイルドカードやCIDR表記の扱いはツールによって異なります。

Javaでは独自の非プロキシホスト設定があり、Dockerではdaemon、CLI、コンテナ、ビルド時で設定箇所が分かれます。

実務では、まずローカルホストを例外に入れ、次に社内ドメインや重要な社内サーバーを追加し、IP範囲指定は動作確認を前提に使うのが安全です。

以上、プロキシの例外設定についてでした。

最後までお読みいただき、ありがとうございました。