PACファイル (プロキシ自動設定ファイル)について

PACファイルとは、Webサイトや社内システムへアクセスするときに、プロキシサーバーを使うか、直接接続するかを自動で判定するための設定ファイルです。

PACは「Proxy Auto-Config」の略で、日本語では「プロキシ自動設定ファイル」と呼ばれます。

企業や学校、官公庁、VPN環境、ゼロトラスト環境などでよく利用されています。

通常のプロキシ設定では、すべての通信に対して同じプロキシサーバーを指定することが多いです。

一方、PACファイルを使うと、アクセス先のURLやホスト名に応じて、通信経路を細かく切り替えられます。

たとえば、社内システムには直接接続し、外部のWebサイトにはプロキシを経由する、といった制御が可能です。

PACファイルの役割

PACファイルの役割は、アクセス先ごとに最適な接続方法を判断することです。

具体的には、次のような制御に使われます。

社内サイトと外部サイトを振り分ける

企業ネットワークでは、社内システムやイントラネットにはプロキシを使わず直接接続し、インターネット上のサイトにはプロキシを経由させる構成がよくあります。

PACファイルを使えば、社内ドメインや社内IPアドレスに対しては直接接続、それ以外はプロキシ経由というように自動で振り分けられます。

特定のサービスだけプロキシを回避する

Web会議ツールやクラウドサービスなどは、プロキシを経由すると通信が遅くなったり、一部機能が正常に動作しなかったりすることがあります。

そのような場合、特定のサービスだけプロキシを使わずに直接接続させる設定が行われることがあります。

ただし、SaaSやクラウドサービスは複数の関連ドメインを使用することが多いため、単純にメインドメインだけを除外しても不十分な場合があります。

実際に設定する際は、サービス提供元が公開しているネットワーク要件を確認することが重要です。

拠点ごとにプロキシを切り替える

東京拠点、大阪拠点、海外拠点など、利用者が接続しているネットワークによって使用するプロキシを変えることもできます。

たとえば、東京オフィスでは東京のプロキシ、大阪オフィスでは大阪のプロキシを使うといった設定です。

これにより、通信経路を最適化し、速度や安定性を高められる場合があります。

障害時に別のプロキシへ切り替える

PACファイルでは、複数のプロキシ候補を指定できます。

最初のプロキシが利用できない場合は、次のプロキシを試す、さらにそれも利用できない場合は別の接続方法を使う、といったフォールバック構成が可能です。

ただし、最後に直接接続へ切り替える設定を入れるかどうかは、セキュリティポリシーによって慎重に判断する必要があります。

PACファイルの基本的な仕組み

PACファイルの中身はJavaScript形式で書かれています。

ただし、通常のWebページで使うJavaScriptとは実行環境が異なります。

PACファイルは、画面表示やWebアプリの処理を行うものではなく、通信時に「どの経路を使うか」を決めるための小さな判定プログラムです。

PACファイルでは、アクセス先のURLやホスト名をもとに、プロキシを使うか直接接続するかを返します。

中心になる関数

PACファイルでは、接続方法を判定するための専用関数が使われます。

この関数は、アクセス先のURL全体やホスト名を受け取り、その通信で使用すべき経路を返します。

返される値によって、ブラウザやOSは次のような判断を行います。

• プロキシを使う
• 直接接続する
• SOCKSプロキシを使う
• 複数のプロキシ候補を順番に試す

通常のJavaScriptとは異なる点

PACファイルはJavaScript形式ですが、通常のWebページで使える機能がそのまま使えるわけではありません。

たとえば、ブラウザの画面を操作する機能、ページ内のHTMLを変更する機能、外部ライブラリを読み込む機能などは基本的に使いません。

PACファイルで使うのは、ホスト名やドメイン、IPアドレス、文字列パターンなどを判定するための専用関数です。

そのため、PACファイルは「Webアプリ用のJavaScript」ではなく、「プロキシ判定用のJavaScript」として理解すると分かりやすいです。

PACファイルで指定できる接続方法

PACファイルでは、アクセス先に応じて複数の接続方法を指定できます。

直接接続

直接接続は、プロキシサーバーを使わずにアクセス先へ接続する方法です。

社内システム、イントラネット、ローカルサーバー、プライベートIPアドレス宛ての通信などで使われることがあります。

ただし、PACファイルで直接接続を指定したからといって、必ず接続できるわけではありません。

ネットワーク経路、DNS、ファイアウォール、VPNの状態などによっては、直接接続を指定しても通信できない場合があります。

HTTPプロキシ

HTTPプロキシは、一般的なプロキシサーバーを経由する指定です。

「HTTPプロキシ」と聞くと、HTTPサイトだけに使うものと思われがちですが、HTTPSサイトへのアクセスでも利用されることがあります。

HTTPS通信では、HTTPプロキシに対してトンネルを作成し、その中で暗号化通信を行う構成が一般的です。

そのため、PACファイルでHTTPプロキシを指定すると、HTTPとHTTPSの両方の通信に影響する場合があります。

SOCKSプロキシ

SOCKSプロキシを利用する指定もあります。

ただし、SOCKSの対応状況は、OS、ブラウザ、アプリケーションによって差があります。

SOCKS4、SOCKS5、HTTPSプロキシなどの指定についても、すべての環境で同じように動作するとは限りません。

そのため、SOCKS系の指定を使う場合は、対象端末や対象ブラウザで事前に検証することが重要です。

複数候補の指定

PACファイルでは、複数の接続候補を順番に指定できます。

たとえば、第一プロキシが使えない場合は第二プロキシを使い、それも使えない場合は直接接続する、というような構成です。

この仕組みは、プロキシサーバーの冗長化や障害対策に役立ちます。

一方で、最後に直接接続へ逃がす設定は、企業のセキュリティ方針によっては問題になることがあります。

プロキシを必ず経由させたい環境では、直接接続へのフォールバックを入れない設計もあります。

PACファイルでよく使われる判定条件

PACファイルでは、アクセス先をさまざまな条件で判定できます。

ホスト名で判定する

ホスト名を使って、特定のサーバーやドメインへのアクセスを判定します。

たとえば、社内システムのホスト名、イントラネットのサーバー名、特定サービスのドメインなどを条件にできます。

実務では、URL全体よりもホスト名を使った判定のほうが安定しやすいです。

ドメインで判定する

特定のドメイン配下にあるサイトをまとめて判定できます。

たとえば、社内ドメインに属するサイトは直接接続し、それ以外はプロキシ経由にする、といった制御が可能です。

ただし、サブドメインだけでなく、ドメイン本体も対象にしたい場合は注意が必要です。

設定の書き方によっては、サブドメインは対象になるものの、ドメイン本体は対象にならないことがあります。

たとえば、外部サービスの「example.com」と、そのサブドメインである「www.example.com」「api.example.com」の両方を対象にしたい場合は、ドメイン本体とサブドメインの両方を意識して設計する必要があります。

ワイルドカードで判定する

PACファイルでは、ワイルドカードのようなパターンを使ってホスト名やURLを判定できます。

たとえば、特定ドメイン配下のすべてのサブドメインを対象にしたい場合などに使われます。

ただし、ワイルドカードを使う場合も、ドメイン本体が対象に含まれるかどうかには注意が必要です。

多くの場合、サブドメインは対象になっても、頂点ドメインそのものは別途考慮する必要があります。

IPアドレスで判定する

アクセス先が特定のIPアドレス範囲に含まれるかどうかを判定できます。

たとえば、プライベートIPアドレス宛ての通信を直接接続にする、といった使い方があります。

ただし、ホスト名をIPアドレスに変換するためにDNS解決が発生する場合があります。

DNS解決を伴う判定を多用すると、Webアクセス全体が遅くなる原因になることがあります。

そのため、PACファイルでは、まずホスト名やドメインなど文字列で判定できる条件を優先し、IPアドレス判定は必要な場合に限定するのが望ましいです。

クライアント端末のIPアドレスで判定する

利用者の端末がどのネットワークに接続しているかによって、プロキシを切り替えることもできます。

たとえば、東京オフィスのIPアドレス帯にいる場合は東京のプロキシ、大阪オフィスのIPアドレス帯にいる場合は大阪のプロキシを使う、といった制御です。

ただし、現代の端末には複数のネットワークインターフェースが存在することがあります。

有線LAN、Wi-Fi、VPN、仮想NIC、セキュリティ製品の仮想アダプタなどがあるため、取得されるIPアドレスが期待どおりとは限りません。

拠点判定に使う場合は、実際の利用環境での検証が欠かせません。

PACファイルとWPADの違い

PACファイルと一緒によく登場するのがWPADです。

WPADは「Web Proxy Auto-Discovery Protocol」の略で、端末がPACファイルの場所を自動的に見つけるための仕組みです。

PACファイルはルール本体

PACファイルは、プロキシを使うか直接接続するかを判断するためのルール本体です。

つまり、通信経路を決める中身そのものがPACファイルです。

WPADはPACファイルを見つける仕組み

WPADは、PACファイルの場所を自動検出するための仕組みです。

端末側で「設定を自動的に検出する」といった設定が有効になっている場合、DHCPやDNSを使ってPACファイルの場所を探しに行くことがあります。

つまり、PACファイルとWPADの関係は次のように整理できます。

PACファイルは「プロキシ判定ルール」、WPADは「そのルールファイルを自動で見つける仕組み」です。

WPADではwpad.datが使われることが多い

手動でPACファイルを指定する場合は、拡張子が「.pac」のファイル名がよく使われます。

一方、WPADでは「wpad.dat」というファイル名が使われることが一般的です。

そのため、PACファイルは必ず「.pac」という拡張子でなければならない、というわけではありません。

重要なのは、クライアントがそのファイルをPACファイルとして読み込めることです。

PACファイルの配布方法

PACファイルは、さまざまな方法で端末に配布できます。

手動設定

端末やブラウザのプロキシ設定画面で、PACファイルのURLを直接指定する方法です。

小規模な環境や検証環境では、この方法が使われることがあります。

ただし、端末数が多くなると管理が大変になるため、大規模な企業環境では別の配布方法が使われることが一般的です。

グループポリシーによる配布

Windowsドメイン環境では、Active Directoryのグループポリシーを使ってPACファイルのURLを配布することがあります。

企業環境ではよく使われる方法です。

端末ごとに手動設定する必要がなく、組織全体で統一した設定を適用できます。

MDMによる配布

MDMを使って、Windows、macOS、iPhone、iPad、Androidなどの端末へPAC設定を配布することもあります。

リモートワークやBYOD、ゼロトラスト環境では、MDMによる設定配布が重要になることがあります。

WPADによる自動検出

WPADを使うと、端末がPACファイルの場所を自動的に検出できます。

設定の手間を減らせる一方で、セキュリティ上の注意が必要です。

不要な環境では無効化し、使う場合はDNSやDHCPを適切に管理する必要があります。

PACファイルのMIMEタイプ

PACファイルをWebサーバーから配布する場合は、適切なMIMEタイプを設定することが推奨されます。

推奨されるMIMEタイプ

PACファイルでは、一般的に「application/x-ns-proxy-autoconfig」というMIMEタイプが使われます。

互換性を考えるなら、このMIMEタイプを設定するのが基本です。

他のMIMEタイプで動作する場合もある

一部の環境では、テキストファイルや汎用バイナリとして配布しても読み込まれることがあります。

ただし、それは「動く場合がある」というだけであり、推奨とは言えません。

OSやブラウザ、セキュリティ製品によって動作が異なる可能性があるため、実務では推奨MIMEタイプを設定するのが安全です。

PACファイルを使うメリット

PACファイルには、通常の固定プロキシ設定にはない柔軟性があります。

アクセス先ごとに通信経路を変えられる

PACファイル最大のメリットは、アクセス先によってプロキシ経由と直接接続を切り替えられることです。

社内システム、外部Webサイト、クラウドサービス、特定ドメインなど、条件に応じた制御が可能です。

大規模環境でも管理しやすい

企業などで多数の端末を管理している場合、すべての端末に同じPACファイルを参照させることで、通信ルールを一元管理できます。

PACファイルを更新すれば、端末側の設定を個別に変更しなくても、新しいルールを反映できます。

拠点別・ネットワーク別の制御ができる

端末がどのネットワークにいるかによって、使用するプロキシを変えられます。

複数拠点を持つ企業では、近いプロキシサーバーを使わせることで、通信速度や安定性を改善できる場合があります。

障害対策に使える

複数のプロキシ候補を指定することで、障害時に別のプロキシへ切り替える構成が作れます。

単一のプロキシサーバーに依存しない設計にできるため、可用性の向上につながります。

PACファイルを使うデメリット・注意点

PACファイルは便利ですが、設計や運用を誤るとトラブルの原因になります。

複雑にしすぎると管理が難しくなる

PACファイルは条件分岐で柔軟に制御できますが、ルールを増やしすぎると管理が難しくなります。

例外ルールが増えすぎると、どの通信がどの経路を通るのか分かりにくくなります。

担当者が変わったときに意図が分からず、修正しにくくなることもあります。

そのため、PACファイルにはコメントや変更履歴を残し、ルールの目的を明確にしておくことが重要です。

DNS解決を多用すると遅くなる可能性がある

PACファイル内でDNS解決を伴う判定を多用すると、Webアクセスが遅くなることがあります。

特に、アクセスのたびにDNS解決が発生するような設計は避けるべきです。

まずはホスト名やドメイン名など、文字列で判定できる条件を優先するのが望ましいです。

HTTPSのURLパス判定に依存しないほうがよい

PACファイルではURLをもとに判定できますが、HTTPSサイトではURLのパスやクエリがPACファイルに渡らない、または制限される場合があります。

そのため、特定のページパスを条件にしてプロキシを切り替える設計は、期待どおりに動作しない可能性があります。

実務では、URLのパスではなく、ホスト名やドメイン単位で判定する設計のほうが安全です。

クライアントごとに挙動が異なる場合がある

PACファイルの挙動は、OS、ブラウザ、アプリケーション、セキュリティ製品、VPNクライアントなどによって差が出ることがあります。

特に、SOCKS系の指定、HTTPS URLの扱い、PACファイルのキャッシュ、端末IPアドレスの取得、WPADの動作などは環境差が出やすい部分です。

本番配布前には、実際に利用する端末・ブラウザ・ネットワーク環境で検証することが重要です。

PACファイルのセキュリティリスク

PACファイルは通信経路を決める重要なファイルです。

設定ファイルというより、ネットワーク制御の一部と考えるべきです。

不正なPACファイルによる通信誘導

悪意あるPACファイルを読み込んでしまうと、通信が攻撃者の用意したプロキシへ誘導される可能性があります。

その結果、フィッシング、中間者攻撃、通信内容の監視、認証情報の窃取などにつながる恐れがあります。

WPADの悪用

WPADは便利な自動検出機能ですが、悪用されるリスクもあります。

特に、信頼できないネットワークや公共Wi-Fiなどでは、不正なWPAD応答によって意図しないPACファイルを取得してしまう可能性があります。

WPADを使わない環境では、自動検出を無効化することが推奨されます。

使う場合は、社内DNSやDHCPを適切に管理し、意図しないPACファイルが配布されないようにする必要があります。

PACファイルの改ざん

PACファイルをHTTPで配布している場合、ネットワーク上で改ざんされるリスクがあります。

手動設定、GPO、MDMなどでPACファイルのURLを明示配布する場合は、可能であればHTTPS配布を検討するとよいでしょう。

ただし、WPADではHTTP配布が一般的であり、HTTPS配布がすべての環境で問題なく使えるとは限りません。

証明書、OS、ブラウザ、ネットワーク構成によって互換性の問題が出る場合があるため、事前検証が必要です。

PACファイル運用時のベストプラクティス

PACファイルを安定して運用するには、設計・検証・管理の3つが重要です。

ルールはシンプルに保つ

PACファイルは、できるだけシンプルに保つことが大切です。

複雑な条件分岐や大量の例外ルールを入れると、トラブル時の原因特定が難しくなります。

まずは基本方針を明確にし、例外ルールは必要最小限にするのが望ましいです。

よく使う条件を先に判定する

PACファイルは通信時に判定されるため、よく使われる条件や軽い判定を先に置くと効率的です。

たとえば、ローカルホスト、単純なホスト名、社内ドメインなど、文字列だけで判定できるものを先に処理し、DNS解決が必要な判定は後ろに回すとよいでしょう。

ドメイン本体とサブドメインを分けて考える

PACファイルでは、サブドメインを対象にしたつもりでも、ドメイン本体が対象外になることがあります。

たとえば、外部サービスのドメインを除外する場合は、「example.com」と「www.example.com」「api.example.com」のようなサブドメインを分けて考える必要があります。

この点は、PACファイルでよく起きる設定ミスのひとつです。

直接接続へのフォールバックは慎重に判断する

プロキシが使えない場合に直接接続へ切り替える設定は、利便性の面では有効です。

しかし、セキュリティ面では注意が必要です。

プロキシを通さない通信が発生すると、ログ取得、Webフィルタリング、マルウェア対策、DLPなどを回避してしまう可能性があります。

企業のセキュリティポリシーによっては、直接接続へのフォールバックを入れないほうが適切です。

コメントや変更履歴を残す

PACファイルは長期運用されることが多く、担当者が変わることもあります。

そのため、各ルールが何のために存在するのかをコメントとして残しておくことが重要です。

また、変更日、変更理由、影響範囲、検証結果などを管理しておくと、トラブル時の切り分けがしやすくなります。

本番配布前に検証する

PACファイルは、OSやブラウザによって挙動が異なる場合があります。

そのため、本番環境へ配布する前に、利用者が実際に使う端末やブラウザで検証する必要があります。

検証では、少なくとも次の点を確認するとよいでしょう。

• 社内サイトに正しく接続できるか
• 外部サイトが想定どおりプロキシ経由になるか
• プロキシ除外したサービスが正常に動作するか
• PACファイルの取得に失敗しないか
• 変更後に正しく反映されるか
• VPN接続時と非接続時で想定どおり動くか
• セキュリティ製品やMDMとの相性に問題がないか

PACファイルでよくあるトラブル

PACファイルを運用していると、いくつかの典型的なトラブルが発生します。

プロキシが効かない

PACファイルを設定したのにプロキシが使われない場合、PACファイルのURLが間違っている、ファイルが取得できない、構文エラーがある、条件分岐が想定と異なる、といった原因が考えられます。

また、OS側のプロキシ設定とブラウザ側のプロキシ設定が異なる場合もあります。

特定サイトだけ表示できない

特定のWebサイトだけ表示できない場合、そのサイトに必要な関連ドメインがPACファイルの条件に含まれていない可能性があります。

特にSaaSやクラウドサービスでは、メインドメイン以外にも認証、API、CDN、静的ファイル配信など複数のドメインが使われます。

また、PACファイルでは直接接続にしているものの、実際にはネットワーク的に直接到達できない、というケースもあります。

Webアクセスが遅い

Webアクセスが遅い場合、PACファイル内の判定処理が原因になっていることがあります。

DNS解決を多用している、条件分岐が多すぎる、PACファイルの取得に時間がかかっている、プロキシ候補のフォールバックに時間がかかっている、といった原因が考えられます。

PACファイルを軽量化し、文字列判定を優先することで改善できる場合があります。

変更が反映されない

PACファイルを変更しても、すぐに端末へ反映されないことがあります。

これは、ブラウザやOSがPACファイルをキャッシュしているためです。

反映されない場合は、ブラウザの再起動、OSのプロキシ設定の再読み込み、キャッシュクリアなどが必要になることがあります。

また、Webサーバー側のキャッシュ制御も重要です。

検証時と本番運用時で、適切なキャッシュ方針を設計する必要があります。

PACファイルとVPN・ゼロトラスト環境

近年では、従来の社内プロキシだけでなく、VPNやゼロトラスト環境でもPACファイルが使われることがあります。

VPN接続時の経路制御

VPN接続時だけ社内システムを直接接続扱いにしたり、特定の通信をVPN経由にしたりする設計があります。

ただし、VPN接続時と非接続時でDNSやルーティングが変わるため、PACファイルの挙動も変わる場合があります。

ゼロトラスト製品との連携

ゼロトラスト製品やSecure Web Gateway製品では、通信をクラウド上のゲートウェイへ誘導するためにPACファイルが使われることがあります。

この場合、独自に複雑なPACファイルを作るよりも、製品ベンダーが提供する推奨設定に従うほうが安定しやすいです。

セキュリティ製品による影響

エンドポイントセキュリティ製品、DLP製品、CASB、SWG、VPNクライアントなどが、プロキシ設定や通信経路に影響することがあります。

PACファイル単体では正しく見えても、他の製品との組み合わせで想定外の動作になる場合があるため、総合的な検証が必要です。

PACファイルを理解するうえで重要な考え方

PACファイルは、単なる設定ファイルではありません。

実質的には、企業や組織のWeb通信をどの経路に流すかを決める、重要な制御ルールです。

ネットワーク設計の視点が必要

どの通信をプロキシ経由にするのか、どの通信を直接接続にするのかを明確にする必要があります。

社内ネットワーク、VPN、クラウド、SaaS、拠点間通信など、全体のネットワーク設計と合わせて考えることが重要です。

セキュリティ設計の視点が必要

プロキシを使う目的が、ログ取得、Webフィルタリング、認証、マルウェア対策、DLPなどである場合、直接接続の扱いは慎重に決める必要があります。

利便性を優先して直接接続を広げすぎると、セキュリティ上の抜け道になる可能性があります。

パフォーマンスの視点が必要

PACファイルの条件分岐が重いと、Webアクセスの体感速度に影響することがあります。

DNS解決を多用しない、条件を整理する、よく使う判定を先に置く、といった工夫が必要です。

運用管理の視点が必要

PACファイルは一度作って終わりではありません。

SaaSのドメイン変更、プロキシサーバーの移行、拠点追加、VPN構成の変更、ゼロトラスト製品の導入などに応じて、継続的に見直す必要があります。

まとめ

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

企業ネットワークでは、社内システムと外部サイトの振り分け、拠点別のプロキシ切り替え、特定SaaSの除外、障害時のフォールバックなどに使われます。

一方で、PACファイルは通信経路を決める重要な仕組みであるため、設定ミスや運用ミスがあると、通信障害やセキュリティリスクにつながる可能性があります。

特に注意すべきポイントは、次の通りです。

• PACファイルは通常のJavaScriptとは異なる実行環境で動作する
• HTTPSではURLのパスやクエリに依存した判定は避けたほうがよい
• ドメイン本体とサブドメインの扱いに注意する
• DNS解決を伴う判定を多用しない
• 直接接続へのフォールバックはセキュリティポリシーに合わせて判断する
• WPADを使う場合はセキュリティリスクを理解する
• OS、ブラウザ、VPN、セキュリティ製品による挙動差を検証する
• 本番配布前に実環境で十分にテストする

PACファイルは、うまく設計すればWeb通信の制御を柔軟に行える便利な仕組みです。

ただし、実務ではネットワーク、セキュリティ、パフォーマンス、運用管理の観点を踏まえて、慎重に設計・検証することが重要です。

以上、PACファイル (プロキシ自動設定ファイル)についてでした。

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