Wget に必要なのはプロキシのアドレスであり、PAC の URL ではない
ブラウザは PAC スクリプトを自動的に評価できますが、GNU Wget はプロキシ設定に実際のプロキシエンドポイントを求めます。
ダウンロード先のために、GNU Wget に実際の転送エンドポイントを指定します。
https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zip最初のサンプル URL を承認済みの HTTP プロキシに、2 番目を目的のファイルに置き換えてください。https_proxy は HTTPS 宛先へのリクエストを選択します。その値はリスナーを示すもので、評価すべき PAC スクリプトではありません。
https://config.example/proxy.pac のような URL は経路選択のデータを指します。これをプロキシ変数に入れても、Wget に JavaScript の実行を求めることにはなりません。GNU Wget のプロキシ入力とインストール済みのバージョンを確認してください。同名の別ツールでは動作が異なる場合があります。
対象の URL についてPAC の結果を取得してください。1 つのエンドポイントをコピーするのが適切なのは、その経路が操作全体で有効な場合だけです。リダイレクトでホストが変わることも、内部宛先が直接接続になることもあります。複雑なポリシーには、そうした判断を保つ対応アダプターまたは管理上の取り決めが必要です。
PAC プログラムをシェルプロファイルに貼り付けたり、未知のスクリプトを無制限のシェルコードとして実行したりするのではなく、承認済みのエンドポイントまたはコマンドライン連携を求めてください。