Ang address ng PAC file at ang endpoint ng proxy ay mukhang mapagpapalit sa isang config file, at hindi sila. Ang isa ay programang patakaran na kailangang suriin para sa bawat URL; ang isa ay host at port na tumatanggap ng koneksyon. Ang curl ay nakakaunawa lamang ng pangalawa. Ang pagpapasa ng address ng PAC sa --proxy ay error sa kategorya na nabigo sa nakalilitong paraan, karaniwang pagkatapos ng mahabang CONNECT timeout patungo sa web server.

Ano talaga ang bawat isa

Mayroon kaAno itoAno ang ginagawa ng curl dito
http://wpad.corp.example/proxy.pacJavaScript na nagbabalik ng proxy o direktang koneksyon para sa isang partikular na URLDinownload ito bilang file at humihinto doon
http://proxy.corp.example:8080Tagapakinig na tumatanggap ng mga kahilingang dumadaan sa proxyGinagamit ito, kasama ang CONNECT para sa mga target na HTTPS

Ito ay sinasabi nang malinaw ng mga FAQ tungkol sa curl: hindi nagbibigay ang curl ng anumang interpretasyon ng JavaScript o PAC. Ang isang balot sa paligid ng curl na nakakaunawa ng PAC ay maaari, ngunit ang curl mismo ay hindi, at walang flag na gumagawa nitong browser.

Bakit gumagana ang browser at ang curl ay hindi

Ang browser ay nag-uugnay sa proxy configuration ng system, kinukuha ang PAC file at pinapatakbo ang mga patakaran nito laban sa URL na binubuksan mo. Ang pagsusuring iyon ang serbisyong ibinibigay ng PAC file, at nangyayari ito sa loob ng browser, hindi sa loob ng iyong terminal.

Ang pag-download ng PAC file gamit ang curl ay nakakakuha lamang ng teksto nito. Hindi nito pinapatakbo ng curl ang patakaran, at ang manu-manong pagbasa nito upang makahanap ng proxy ay manu-manong bersyon ng parehong pagsusuri, na may parehong pagkakataong pumili ng maling sangay. Kung babasahin mo ito, basahin ang return statement na tumutugma sa iyong host sa halip na ang unang pangalan ng proxy sa file. Karamihan sa mga PAC file ay may ilan, at isang sangay lamang ang naaangkop sa iyo.

Para sa isang aprubadong HTTP proxy at aprubadong serbisyong HTTPS, ang isang halimbawang kahilingan ay:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Ang unang address ay ang tagapakinig ng proxy, ang pangalawa ay ang serbisyong gusto mo. Ito ay mga halimbawang endpoint at hindi isang pagsubok na ginawa ng sinuman, kaya palitan ang mga ito ng scheme, port at daloy ng pagpapatunay ng iyong organisasyon.

Piliin ang proxy para sa patutunguhang ito

Itanong sa administrator kung aling proxy ang pinipili ng patakaran para sa URL na kailangan mo, hindi kung aling proxy ang pag-aari ng organisasyon. Maaaring magbalik ang mga patakaran ng PAC ng iba't ibang resulta para sa mga panloob na serbisyo, pampublikong site at kalagayan ng paglilipat kapag may aberya, at ang patakarang umaangkop sa iyong URL ngayon ay maaaring umangkop sa iba pagkatapos ng pag-edit.

Kung ang daloy ng trabaho ay nangangailangan ng higit sa isang kilalang kahilingan, gumamit ng static na setting na sinusuportahan ng administrator o aprubadong integrasyong nakakaunawa ng PAC. Ang pag-hardcode ng isang kopyadong address ay gumagana hanggang sa araw na magbago ang patakaran at wala nang maalala kung bakit napili ang address na iyon.

Pagkatapos tingnan kung ano ang namamana ng curl. Ang mga environment variable ng proxy at NO_PROXY ay maaaring mangibabaw o magbukod sa proxy na ipinasa mo, at ang pagbubukod na tumutugma sa iyong target ay direktang nagpapadala ng kahilingan nang tahimik. Panatilihin ang nilalayong patakaran sa halip na burahin ang bawat pagbubukod o pilitin ang lahat sa isang address. Patakbuhin ang kahilingan nang isang beses gamit ang -v at tingnan kung aling address talaga ito kumonekta.

Panatilihing magkahiwalay ang dalawang pagkakakilanlang TLS

Sa isang HTTPS proxy, dalawang koneksyong TLS ang sangkot: ang sa iyo patungo sa proxy at ang sa proxy patungo sa patutunguhan. Bawat isa ay may sariling pagkakakilanlang dapat i-verify, at ang pag-off ng verification para sa alinman sa mga ito ay hindi pag-aayos ng PAC, ito ay pangalawang problema na idinagdag sa una.

Iwanang nakabukas ang verification at basahin ang nabigong resulta. Ang hamon sa pagpapatunay ng proxy, ang proxy na hindi maabot at ang pagtanggi ng website ay tatlong magkaibang resulta, at ang una lamang ang tungkol sa mga kredensyal. Kailangan pa ring magbigay ng pinapayagang landas ang VPN patungo sa pribadong proxy, kabilang ang paglutas ng pangalan para sa host ng proxy mismo, bago magtagumpay ang alinman sa mga ito.

Isulat ang endpoint, scheme, port, paraan ng pagpapatunay, mga pagbubukod at landas ng VPN patungo sa proxy. Ang talaang iyon ang gumagawa sa susunod na kahilingan na maaaring kopyahin, at iyon ang pagkakaiba ng pagkilala sa iyong proxy at paghula tungkol dito.

Kaugnay na mga artikulo