PAC テストの結果からブラウザの実際の経路まで
PAC 関数が返す経路を、ファイルの配信、ブラウザによる採用、プロキシへの到達、リクエストの最終的な経路から切り分けます。
PAC テスターは PROXY proxy.example:8080 を返します。有用な結果です。ただし、ブラウザの構成を検証済みと呼ぶ前に、答えるべき問いがほかにもあります。
| 問い | 確認すべきこと |
|---|---|
| このスクリプトはこの入力に対して何を返すか | 評価器、入力 URL、ヘルパー関数の結果 |
| ブラウザはこのコピーを取得したか | 設定された PAC URL と配信・キャッシュの証拠 |
| ブラウザは返された経路を使ったか | ブラウザのプロキシ解決と接続の診断 |
| その経路はリクエストを運べたか | 選択されたエンドポイントの接続とプロキシとのやり取り |
pacparser のようなツールは、自前の対応ヘルパーで PAC ロジックを評価します。対象ブラウザの構成検出、ポリシー、キャッシュ、接続の仕組み全体を動かしているわけではありません。
入力は比較可能に保ちます。URL スキーム、ホスト名の表記、DNS 応答、与えるクライアントアドレスが違えば、正当な結果も変わり得ます。別のネットワークでの実行は、スクリプトに不具合がなくても別の分岐を通ることがあります。
ブラウザのポリシーが別の PAC URL や固定プロキシを選ぶこともあります。ディスク上のファイルを編集しても、ブラウザが再取得した証明にはなりません。Chrome では、PAC の更新は記憶された不良プロキシの消去とは異なります。結果とともに、ファイルの正確な版と関連する利用側の設定を記録します。
論理の問題を絞り込むにはオフライン評価を使います。採用と経路を確かめるには実クライアントの診断を使います。スクリプトの結果が正しいのにプロキシに通信が見えないなら、動作している規則を書き直す前にその隔たりを調べます。