Wget нужен адрес прокси, а не URL-адрес PAC
Браузер может автоматически вычислять PAC-скрипт, тогда как GNU Wget ожидает в настройках прокси реальную конечную точку прокси.
Укажите GNU Wget реальную конечную точку перенаправления для цели загрузки:
https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zipЗамените первый пример URL на одобренный HTTP-прокси, а второй — на нужный файл. https_proxy выбирает запросы к целям HTTPS; его значение задаёт прослушиватель, а не PAC-скрипт для вычисления.
URL вида https://config.example/proxy.pac указывает на данные выбора маршрута. Помещение его в переменную прокси не заставляет Wget выполнять JavaScript. Проверьте входные данные прокси GNU Wget и установленную версию; другая утилита с похожим именем может вести себя иначе.
Получите результат PAC для соответствующих URL. Копировать одну конечную точку уместно только тогда, когда этот маршрут действует на протяжении всей операции. Перенаправления могут менять хосты, а внутренние назначения могут быть прямыми. Сложная политика требует поддерживаемого адаптера или управленческого решения, сохраняющего эти решения.
Запросите одобренную конечную точку или интеграцию через командную строку вместо того, чтобы вставлять программу PAC в профиль shell или запускать незнакомый скрипт как неограниченный код shell.