プロキシ自動設定

プロキシ自動設定（プロキシじどうせってい、PAC: proxy auto-config）ファイルは、ウェブブラウザやその他のユーザーエージェントが、与えられたURLを取得するための適切なプロキシサーバ（アクセスメソッド）を自動選択する方法を定義する。
PACファイルにはJavaScriptの関数“codice_1”が書かれている。この関数は一つあるいは複数のアクセスメソッド指定を含む文字列を返す。これらの指定によりユーザーエージェントは特定のプロキシサーバを使って接続するか、または直接に接続する。
アクセスメソッドを複数指定しておくことにより、一つのプロキシが反応しない場合のフォールバック（代替手段）を提供できる。ブラウザは他のURLにリクエストを送る前に、このPACファイルを取得する。PACファイルのURLは手動で設定しておくか、あるいはWeb Proxy Auto-Discovery Protocolにより自動的に決定される。
プロキシ設定手法の概要.
現代的なウェブブラウザはいくつかのレベルの自動化を実装している。ユーザは必要に応じてそのレベルを選ぶことができる。一般的に次のレベルが実装される：
プロキシ設定.
コンピュータがインターネット通信をするためには、 オペレーティングシステム (例：Microsoft Windows, macOS, Linux)に多くの設定をする必要がある。これらの設定はインターネットサービスプロバイダ(ISP)から与えられるのが普通である。ネットワークに接続するためには匿名（プロキシサーバを使うための代理）あるいは実際の設定のいずれかを使うことができる。
PAC ファイル.
プロキシ自動設定ファイル（PACファイル）は、1996年にNetscape Navigator 2.0 のためにNetscapeによって最初に設計され
、それは最低限一つのJavaScript関数codice_1を定義したテキストファイルであった。この関数の二つの引数の意味は：codice_4が目的のURLで、codice_5がそのURLから得られるホスト名である。慣例として、PACファイルの名前はcodice_6とする。WPAD標準はcodice_7を使う。
PACファイルを使うには、まずPACファイルをHTTPサーバに公開しておき、クライアントのユーザーエージェントは、ブラウザのプロキシ接続設定にPACファイルのURLを入力しておくか、またはWPADプロトコルを通じてのいずれかにより、そのPACファイルを使うよう指示される。
多くのクライアントは、完全性のために、また互換性を高めるために、HTTPリプライで返されたMIMEタイプが何であれ、PACファイルのスクリプトを処理するが、HTTPサーバはPACファイルのMIMEタイプとしてcodice_8 または codice_9のいずれかを宣言しておくべきである。
これらのMIMEタイプのどちらを使った方がよいという根拠はほとんどないが、codice_8がcodice_9よりも多くのクライアントでサポートされていると想定するのは妥当だろう。なぜなら前者は最初のNetscapeの仕様で定義されたものであり、後者はもっと最近になってから使われるようになったものだからだ。
PACファイルの非常に単純な例を示す:
function FindProxyForURL(url, host)
 return "PROXY proxy.example.com:8080; DIRECT";
この関数は、codice_12サーバのポート番号8080上のプロキシを通じて全てのページを取得するようブラウザに指示する。このプロキシが応答に失敗した場合、ブラウザはプロキシを使わず目的のウェブサイトに直接接続する。後者の直接接続はファイアウォールあるいはその他の中間的なネットワーク装置が、プロキシ以外を発信元とする要求を拒否する設定になっている場合には失敗する（このような設定は法人組織内のネットワークでは一般的である）。
利用できるJavaScript関数をFindProxyForURL関数の中で幾つか使った、より複雑な例を示す：
function FindProxyForURL(url, host) {
 // example.com以下のドメインにある我々のローカルなURLに対してはプロキシ不要:
 if (shExpMatch(host, "*.example.com"))
 return "DIRECT";
 // 下記のネットワーク内のURLには
 // fastproxy.example.comのポート8080を通じてアクセスする:
 if (isInNet(host, "10.0.0.0", "255.255.248.0"))
 return "PROXY fastproxy.example.com:8080";
 // その他のリクエストはproxy.example.comのポート8080を通じて出る。
 // 応答がなければ、直接WWWに出る：
 return "PROXY proxy.example.com:8080; DIRECT";
制約.
PAC 文字エンコード.
Mozilla FirefoxやInternet Explorerなどのブラウザはシステムのデフォルトの文字コードのPACファイルしかサポートしないので、UTF-8などのUnicodeでエンコードされたものはサポートできない。
codice_13.
codice_13関数（および他の類似の関数）はDNSルックアップを実行するが、DNSサーバが応答しない場合、ブラウザを長時間ブロックすることがある。
Microsoft Internet Explorer 5.5以上でドメイン名によりプロキシ自動設定結果をキャッシュすることは、PAC標準の柔軟性を制限してしまう。実質的に、URLのパスに基づいてではなく、ドメイン名に基づいてプロキシを選ぶことになる。それを回避するにはレジストリを編集してプロキシ自動設定結果のキャッシュを無効にする必要がある（詳しくは発展学習のBoyne Pollardの記事を参照）。
Internet ExprolerのPAC設定を使用する.NET 2.0 Frameworkなどの他のWindowsコンポーネントとの互換性のために、codice_15関数内では、ホストのドメイン名ではなく、常にIPアドレスを用いることが推奨される。たとえば次のように書く：
if (isInNet(host, dnsResolve(sampledomain), "255.255.248.0")) // .NET 2.0 は適切にプロキシを解決するだろう
if (isInNet(host, sampledomain, "255.255.248.0")) // .NET 2.0 はプロキシを適切に解決できないだろう
PACファイルが利用できない場合は直接接続にフェイルオーバーするのが現在の慣例である。
ネットワーク設定を切り替えた少し後（例：VPNに入るとき、あるいは出るとき）、codice_13がDNSキャッシュによる古い結果を返すことがある。
たとえば、Firefoxは通常20個のドメインのエントリーを60秒キャッシュしている。これは設定変数codice_17 およびcodice_18で設定できる。システムのDNSキャッシュを捨てることも役に立つ場合がある、これは例えばLinuxではsudo service dns-clean startで実行できる。
codice_19.
codice_19関数は不正確であったり使えない結果（例えば、ローカルホストのIPアドレスcodice_21）を返すことがしばしば報告されてきた。システムのホストファイル（たとえばLinuxではcodice_22）で当該マシンのホスト名を参照する行をすべて削除する一方、codice_23の行はそのままにしておくことが役に立つ場合がある。
Internet Explorer 9では、codice_24がcodice_25 を返すので、これが回避策として使える。
codice_19関数は、その装置が一つのIPv4アドレスを持つと想定している。その装置が複数のIPv4アドレスあるいはIPv6アドレスを持つ場合、その結果は未定義となる。
セキュリティ.
2013年、研究者らはプロキシ自動設定のセキュリティ上の危険性を警告し始めた 。その脅威とは、PACを使って被害者のブラウザの通信先を攻撃者が支配しているサーバにすり替えてしまうというものなどである。
その他.
その他の制約は、JavaScriptエンジンのローカルマシンに対する制約と関係したものである。
発展機能.
より発展したPACファイルは、リクエストがネットワークへ送られる前に、プロキシの負荷を減らし、負荷分散、フェイルオーバーを行い、更にはブラックリスト/ホワイトリストの作成まで行うことができる。複数のプロキシを返すこともできる：
return "PROXY proxy1.example.com:80; PROXY proxy2.example.com:8080";