Wget har brug for en proxyadresse, ikke en PAC-URL
En browser kan evaluere et PAC-script automatisk, mens GNU Wget forventer et faktisk proxyendepunkt i sine proxyindstillinger.
Giv GNU Wget et faktisk videresendelsesendepunkt for downloaddestinationen:
https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zipErstat den første eksempel-URL med den godkendte HTTP-proxy og den anden med den tilsigtede fil. https_proxy vælger anmodninger til HTTPS-destinationer; dets værdi angiver lytteren, ikke et PAC-script, der skal evalueres.
En URL som https://config.example/proxy.pac peger på data til rutevalg. At sætte den i proxyvariablen får ikke Wget til at køre JavaScript. Kontroller GNU Wgets proxyinddata og den installerede version; et andet værktøj med lignende navn kan opføre sig anderledes.
Hent PAC-resultatet for de pågældende URL'er. Det er kun passende at kopiere ét endepunkt, når den rute gælder gennem hele handlingen. Omdirigeringer kan ændre værter, og interne destinationer kan være direkte. En kompleks politik kræver en understøttet adapter eller en ledelsesordning, der bevarer disse beslutninger.
Bed om det godkendte endepunkt eller kommandolinjeintegration i stedet for at indsætte PAC-programmet i en shell-profil eller køre et ukendt script som ubegrænset shell-kode.