curl ne more prebrati vaše datoteke PAC: posredujte namesto nje proxy
PAC je pravilnik JavaScript; curl želi končno točko. Vprašajte, kateri proxy pravilnik izbere za vaš URL, posredujte ga in spremljajte NO_PROXY in TLS.
Naslov datoteke PAC in končna točka proxyja sta v konfiguracijski datoteki videti zamenljiva, pa nista. Eno je program pravilnika, ki ga je treba ovrednotiti za vsak URL; drugo je gostitelj in vrata, ki sprejemata povezave. curl razume le drugo. Posredovanje naslova PAC v --proxy je kategorijska napaka, ki ne uspe na zmeden način, običajno po dolgem čakanju CONNECT na spletni strežnik.
Kaj je vsak od njiju v resnici
| Imate | Kaj je to | Kaj curl počne s tem |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript, ki za dani URL vrne proxy ali neposredno povezavo | Prenese ga kot datoteko in se tam ustavi |
http://proxy.corp.example:8080 | Poslušalec, ki sprejema zahteve prek proxyja | Uporabi ga, vključno s CONNECT za cilje HTTPS |
To jasno pove pogosta vprašanja o curl: curl ne ponuja razlage JavaScripta niti PAC. Ovoj okoli curl, ki razume PAC, lahko to počne, a curl sam ne, in nobena zastavica ga ne spremeni v brskalnik.
Zakaj brskalnik deluje, curl pa ne
Brskalnik se poveže s sistemsko konfiguracijo proxyja, prenese datoteko PAC in izvede njena pravila za URL, ki ga odpirate. Ta ocena je storitev, ki jo ponuja datoteka PAC, in se zgodi znotraj brskalnika, ne v vašem terminalu.
Prenos datoteke PAC s curlom prinese le njeno besedilo. To ne prisili curla, da izvede pravilnik, in ročno branje, da bi našli proxy, je ročna različica iste ocene, z enako možnostjo izbire napačne veje. Če jo berete, berite stavek return, ki ustreza vašemu gostitelju, ne prvega imena proxyja v datoteki. Večina datotek PAC jih vsebuje več, in le ena veja velja za vas.
Za odobren proxy HTTP in odobreno storitev HTTPS je ilustrativna zahteva:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusPrvi naslov je poslušalec proxyja, drugi je storitev, ki jo želite. To so primerne končne točke in ne preizkus, ki bi ga kdo izvedel, zato jih zamenjajte s shemo, vrati in potekom overjanja vaše organizacije.
Izberite proxy za ta cilj
Vprašajte skrbnika, kateri proxy pravilnik izbere za URL, ki ga potrebujete, ne kateri proxy ima organizacija. Pravila PAC lahko vrnejo različne rezultate za notranje storitve, javna mesta in stanja preklopa ob okvari, in pravilo, ki danes ustreza vašemu URL, lahko po spremembi ustreza drugemu.
Če delovni tok potrebuje več kot eno znano zahtevo, uporabite statično nastavitev, ki jo podpira skrbnik, ali odobreno integracijo, ki razume PAC. Trdo kodiranje enega prepisanega naslova deluje do dneva, ko se pravilnik spremeni in se nihče več ne spomni, zakaj je bil ta naslov izbran.
Nato poglejte, kaj curl podeduje. Spremenljivke okolja proxyja in NO_PROXY lahko preglasijo ali izključijo posredovani proxy, in izključitev, ki ustreza vašemu cilju, pošlje zahtevo neposredno brez opozorila. Ohranite predvideni pravilnik, namesto da brišete vsako izključitev ali silite vse skozi en naslov. Izvedite zahtevo enkrat z -v in preverite, na kateri naslov se je dejansko povezala.
Držite obe identiteti TLS ločeno
Pri proxyju HTTPS sta v igri dve povezavi TLS: vaša do proxyja in povezava proxyja do cilja. Vsaka ima svojo identiteto za preverjanje, in izklop preverjanja za katero koli od njiju ni popravek PAC, ampak druga težava, dodana prvi.
Pustite preverjanje vklopljeno in preberite napako, ki jo dobite. Izziv overjanja proxyja, nedosegljiv proxy in zavrnitev spletnega mesta so trije različni izidi, in le prvi se nanaša na poverilnice. VPN mora še vedno zagotoviti dovoljeno pot do zasebnega proxyja, vključno z razreševanjem imen za samega gostitelja proxyja, preden karkoli od tega uspe.
Zapišite končno točko, shemo, vrata, metodo overjanja, izključitve in pot VPN do proxyja. Prav ta zapis naredi naslednjo zahtevo ponovljivo, in v njem je razlika med poznavanjem svojega proxyja in ugibanjem o njem.