WPAD は解決するのに、ブラウザーは 404 を受け取る

wpad という名前は想定どおりのマシンに解決されています。それは心強いことですが、まだ始まりにすぎません。ブラウザーはそのマシンからファイルを要求し、PAC スクリプトを受け取る必要があります。

有用な手がかりは Web サーバーのアクセスログにあります。クライアントは /wpad.dat を要求し、HTTP 404 を受け取りました。手動で開いた PAC URL は別のホスト名を使っている可能性があります。両方の名前が同じサーバーに届いても、異なる仮想ホストが選択されることがあります。

クライアントが送った要求を追跡する

検出が選択した正確な URL、HTTP Host の値、パス、応答を確認します。通常のブラウザータブで都合のよい PAC URL を開いても、自動検出がその URL を要求したことにはなりません。

短い名前と完全修飾名の両方が想定される場合は、意図した Web ホストがそれらの名前を明示的に処理するように構成します。/wpad.dat が既定のドキュメントルートや無関係なアプリケーションではなく、正しいファイルにマップされていることを確認してください。

エラーページではなくスクリプトを返す

応答のステータスだけでなく本文も確認します。サインインページ、ブランド付きのエラードキュメント、リダイレクトは手動で見るともっともらしく見えますが、リゾルバーが期待する PAC スクリプトではありません。Chromium は厳格なPAC ダウンロードの要件を文書化しており、HTTP 200 応答も含まれます。

配信が成功した後に てから初めて FindProxyForURL() をデバッグする意味があります。そのホスト名ルールを変えても、ブラウザーが取得できなかった 404 を修復することはできません。

また、PAC Web サーバーと、そのスクリプト内で指定されたフォワードプロキシを区別してください。同じマシンを共有していても、一方のサービスのアクセスログの記録は、もう一方のサービスが利用者の宛先要求を処理した証拠にはなりません。