「Resolving Host in Proxy Script」で止まる?PAC ファイルを確認する
ブラウザは、どのプロキシを使うかを決める間に DNS を待つことがあり、それはページをダウンロードする接続を開く前のことです。
ステータスには「Resolving host in proxy script」と表示されるのに、プロキシサーバーを変えてもほとんど変わりません。これは有用な手がかりです。ブラウザはまだリクエストの送り先を決めているのかもしれません。
PAC ファイルは DNS に依存するチェックを実行できます。そのチェックが到達不能なリゾルバーを待ったり、不要な問い合わせを繰り返したりすると、選択したプロキシが何かを受け取る前にページの読み込みが止まることがあります。
1. 停止箇所を特定する
影響を受ける URL を 1 つ選び、遅延が PAC ファイルの取得中、評価中、返されたプロキシへの接続中のどこで起きるかを切り分けます。プロキシのアクセスログが空であることは最初の 2 段階と整合しますが、ブラウザが直接経路を使った証拠にはなりません。
次に、どのルールが DNS を必要とするかを調べます。Microsoft の PAC のパフォーマンスに関するガイダンス は、不要な DNS 依存の処理を避けることを勧めています。ホスト名の等値チェックは、そのホスト名を解決してサブネットを確認するのと同じ情報を必要としません。
2. 不要な DNS 処理を取り除く
既知の ホスト名の例外 は、広範なアドレスベースのチェックより前に判定できることがよくあります。残りのポリシーが実際にそのアドレスを必要とする場合にだけ名前を解決してください。後続の複数の条件が同じ値を必要とするなら、結果をローカル変数に保持します。
先頭に無条件の DIRECT リターンを追加して遅いスクリプトを「修正」しないでください。それは遅延とともにルーティングの判断まで取り除いてしまいます。
マシン固有の DNS 回避策には根拠が必要です。ファイル共有を有効にしたり、すべてのノート PC の hosts ファイルを書き換えたりするのは、遅いルーティングスクリプトへの最初の対応としては不適切です。影響を受けるネットワークでリゾルバーとホスト名の挙動を、特にネットワーク変更後に確認し、PAC は実際の判断経路がそれを求める箇所だけ変更してください。