「認証プロキシ爆発しろ！」が自動構成スクリプトに対応しました

認証プロキシをなんとかするためのツールであるところの「認証プロキシ爆発しろ！」ですが、 プロキシ設定の自動構成スクリプトに対応しました。 自動構成スクリプト（.pacファイル）によって複数のプロキシを使い分けているような環境では、 「認証プロキシ爆発しろ！」は自動構成スクリプトの内容に応じた適切なプロキシに対して中継を行うようになりました。

今回のバージョンアップに伴って、設定の変更が必要になります。 以下、それも含めた説明など。

• ユーザーへの影響
• 従来の動きと問題点
• 新しい動き
• 設定変更の必要性
• 問題など

ユーザーへの影響

現在「認証プロキシ爆発しろ！」をお使いの方のうち、 以下の条件に該当する方は設定変更の必要があります。

• コントロールパネルの「インターネットオプション」-「接続」-「LANの設定」の「自動構成」 （Windows 10の「設定」で言えば「ネットワークとインターネット」-「プロキシ」の「自動プロキシセットアップ」）が 有効になっている環境下で「認証プロキシ爆発しろ！」をお使いの方。

と言っても、 ver 1.0.17.0以降のGUI版「認証プロキシ爆発しろ！」を起動すると、 変更の必要のある場合は「設定を推奨値にするか？」という画面が出ますので、 「はい」を押せばほとんどの場合大丈夫です。

設定変更の必要性の詳細を知りたい方は、 以下の説明をお読みください。

従来の動きと問題点

従来の「認証プロキシ爆発しろ！」において、 通信の中継先となるプロキシ（「実際のプロキシ」）はひとつだけでした。 通信の中継を開始する際に、 「実際のプロキシ」のアドレスを自動検出し、 そのアドレスに対して中継を行っていました。

一方、 多くの環境では自動構成スクリプト（.pacファイル）によるプロキシの自動構成が行われています。 この自動構成スクリプトでは、 通信元のアドレスや通信先のURLに応じて複数のプロキシを使い分けるということができます。 「認証プロキシ爆発しろ！」はこのような環境で複数存在する「実際のプロキシ」を使い分けて中継を行うことができませんでした。

というか、 私がこのツールをふだん使っている環境で、 近々複数のプロキシの使い分けが必須になりそうな状況でして、 そのために真面目に対応する気になったんですけれどもね。

新しい動き

PCのユーザー環境でプロキシ設定の自動検出や自動構成スクリプトが有効になっており、 かつ、 「認証プロキシ爆発しろ！」の「認証プロキシ」設定が「自動検出する」になっている場合、 「認証プロキシ爆発しろ！」は自動構成スクリプトが返す「実際のプロキシ」に対して中継を行うようになりました。

設定変更の必要性

変更が必要になる設定は、 「認証プロキシ爆発しろ！」の設定の「プロキシ」-「システム設定書換え」-「中継時の設定」にある以下の二つの項目です。

• ローカルアドレスにはプロキシサーバーを使用しない
• 次で始まるアドレスにはプロキシを使用しない

従来は「認証プロキシ爆発しろ！」を通す必要のないアドレスをここに指定していました。

今後、自動構成スクリプトが有効な環境においては、 いったんすべてのhttp通信は「認証プロキシ爆発しろ！」が中継し、 その内部で自動構成スクリプトの結果に応じて切り分けを行います。 その切り分けには「プロキシを通さない」という判断も含まれます。

なので、この場合、 上の「中継時の設定」は原則不要になります。 ぜんぶ「認証プロキシ爆発しろ！」を通せばよい。 まあ、全通信を中継するオーバーヘッドを考えると、 「プロキシを通さないことが確実なアドレス」は指定してもよいかもしれません。 「ローカルアドレスにはプロキシサーバーを使用しない」ぐらいが実用的ではないでしょうか。 ということで、新しい設定の推奨値は『「ローカルアドレスにはプロキシサーバーを使用しない」のみ有効』にしています。

問題など

「認証プロキシ爆発しろ！」による中継下で、 IEやChromeでは問題がないのに、 Edgeで「プロキシサーバーに接続できません」というエラーが出ることがあります。 現在気づいているケースとしては以下があります。

• 新しいタブを開いた際の「新しいタブ」ページの「マイ フィード」の項
• プロキシの内側にあるサイトのページ（外部ページは問題ない）

後者の正確な条件はよくわかりません。 ひょっとしたら、Active Directoryのドメインが関係しているのかも。

この問題の原因は分かりません。 このケースではそもそも「認証プロキシ爆発しろ！」に接続が来ていません。 Edgeが内部でプロキシの要不要をどう判定しているのかが謎。

あと、 ほとんどのhttp通信を「認証プロキシ爆発しろ！」に通すことになるので、 以前よりオーバーヘッドがかかるようになります。

現状、（httpsではない）普通のhttpではレスポンスを返す際にチャンク転送をサポートしていない（まとめて返している）ので、 体感的に遅く感じる場合があります。 これは以前からの問題なんだけど、今回の変更でより目立ちやすくなったかも。

そのうちなんとかしたい。