Wget се нуждае от адрес на прокси, а не от PAC URL
Браузърът може автоматично да изпълнява 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 код.