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.