PAC-bestânslevering moat wurkje foar de proxy-konfiguraasje
Meitsje de PAC-download berikber foardat de browser de proxyrjochtlinen deryn beoardielet.
In PAC-bestân fertelt in browser hoe't er oare tsjinsten berikke moat. De levering fan it bestân sels moat wurkje foardat dy ynstruksjes beskikber binne.
De PAC-downloader fan Chromium is gjin gewoane ljepblêd-oanfraach. Syn proxydokumintaasje seit dat PAC-bestannen nea fia in proxy ophelle wurde. In PAC-URL dy't allinnich fia de proxy berikber is dy't yn dat bestân neamd wurdt, makket dêrom in opstartprobleem.
Der binne oare leveringsbeheiningen: de downloader kin gjin gewoane HTTP-autentikaasje-oanfraach sjen litte of in kliïntsertifikaat oanbiede, en bykommende sertifikaatnetwurk-ophellingen binne beheind. In wurkjend ljepblêd dat yn in al konfigurearre browser iepene is, is gjin genôch bewiis dat in nije PAC-ophelling slagje kin.
Set it bestân op in einpunt dat berikber is fanút de bedoelde begjinnetwurken, mei in fertrouwens- en tagongsregeling dy't de echte brûker stipet. Hâld de leveringsfoarskôften fan it bestân skieden fan 'e brûkersautentikaasje fan 'e proxy sels.
Foar rûnreizgjende klanten, nim it netwurk op wêryn't de konfiguraasje foar it earst nedich wurdt. In cachet skript kin in leveringsflater ferbergje oant in nij profyl, ferrin of netwurkferoaring in nije ophelling útlokket.
Twa proxy-adressen yn it skript tafoegje kin de rûte net reparearje dy't nedich is om it skript sels te krijen.