curl не можа чытаць ваш PAC-файл: перадайце замест яго проксі
PAC — гэта палітыка на JavaScript; curl патрэбен канчатковы адрас. Спытайце, які проксі палітыка выбірае для вашага URL, перадайце яго і сачыце за NO_PROXY і TLS.
Адрас PAC-файла і канчатковы адрас проксі ў файле канфігурацыі выглядаюць узаемазаменнымі, але гэта не так. Адзін — гэта праграма палітыкі, якую трэба вылічыць для кожнага URL; другі — гэта хост і порт, якія прымаюць злучэнні. curl разумее толькі другі. Перадача адраса PAC у --proxy — гэта памылка катэгорыі, якая правальваецца заблытаным чынам, звычайна пасля доўгага чакання CONNECT да вэб-сервера.
Што насамрэч ёсць кожнае з іх
| У вас ёсць | Што гэта | Што curl з ім робіць |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript, які вяртае проксі або прамое злучэнне для зададзенага URL | Атрымлівае яго як файл і спыняецца на гэтым |
http://proxy.corp.example:8080 | Слухач, які прымае праксіраваныя запыты | Выкарыстоўвае яго, уключаючы CONNECT для мэт HTTPS |
Гэта ясна сказана ў FAQ па curl: curl не прадастаўляе інтэрпрэтацыі JavaScript ці PAC. Абгортка вакол curl, якая ўмее PAC, можа гэта рабіць, але сам curl — не, і ніводзін сцяг не робіць з яго браўзер.
Чаму браўзер працуе, а curl — не
Браўзер інтэгруецца з сістэмнай канфігурацыяй проксі, загружае PAC-файл і выконвае яго правілы для URL, які вы адкрываеце. Гэтае вылічэнне — паслуга, якую дае PAC-файл, і яно адбываецца ўнутры браўзера, а не ўнутры вашага тэрмінала.
Загрузка PAC-файла праз curl атрымлівае яго тэкст. Гэта не прымушае curl выконваць палітыку, а чытанне яго ўручную для пошуку проксі — гэта ручная версія таго ж вылічэння з той жа імавернасцю выбраць не тую галіну. Калі вы ўсё ж чытаеце, чытайце аператар return, які адпавядае вашаму хосту, а не першае імя проксі ў файле. Большасць PAC-файлаў змяшчаюць некалькі, і толькі адна галіна датычыцца вас.
Для ўхваленага HTTP-проксі і ўхваленай службы HTTPS ілюстрацыйны запыт такі:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusПершы адрас — гэта слухач проксі, другі — служба, якую вы хочаце. Гэта прыкладныя канчатковыя адрасы, а не тэст, які хтосьці праводзіў, таму падстаўце схему, порт і працэс аўтэнтыфікацыі вашай арганізацыі.
Выберыце проксі для гэтай мэты
Спытайце ў адміністратара, які проксі палітыка выбірае для патрэбнага вам URL, а не якім проксі валодае арганізацыя. Правілы PAC могуць даваць розныя вынікі для ўнутраных службаў, публічных сайтаў і станаў пераключэння пры збоі, і правіла, якое сёння адпавядае вашаму URL, пасля праўкі можа адпавядаць іншаму.
Калі працэсу патрэбна больш за адзін вядомы запыт, выкарыстоўвайце статычную наладу, якую падтрымлівае адміністратар, або ўхваленую інтэграцыю, якая разумее PAC. Жорсткае кадаванне аднаго скапіяванага адраса працуе да таго дня, калі палітыка зменіцца і ніхто не ўспомніць, чаму быў выбраны гэты адрас.
Затым паглядзіце, што curl атрымлівае ў спадчыну. Зменныя асяроддзя проксі і NO_PROXY могуць перакрыць або выключыць перададзены вамі проксі, а выключэнне, якое адпавядае вашай мэце, моўчкі адпраўляе запыт напрамую. Захоўвайце прадугледжаную палітыку, а не выдаляйце ўсе выключэнні ці ганіце ўсё праз адзін адрас. Выканайце запыт адзін раз з -v і праверце, да якога адраса ён насамрэч падключыўся.
Трымайце дзве ідэнтычнасці TLS асобна
Пры HTTPS-проксі задзейнічаны два злучэнні TLS: ваша да проксі і проксі да мэты. Кожнае мае сваю ідэнтычнасць для праверкі, і адключэнне праверкі для любога з іх — гэта не выпраўленне PAC, а другая праблема, дададзеная да першай.
Трымайце праверку ўключанай і чытайце атрыманую памылку. Запыт аўтэнтыфікацыі проксі, недаступны проксі і адмова сайта — гэта тры розныя вынікі, і толькі першы тычыцца ўліковых даных. VPN усё яшчэ павінен забяспечыць дазволены шлях да прыватнага проксі, уключаючы разбор імёнаў для самога хоста проксі, перш чым што-небудзь з гэтага атрымаецца.
Запішыце канчатковы адрас, схему, порт, метад аўтэнтыфікацыі, выключэнні і шлях VPN да проксі. Гэты запіс і робіць наступны запыт узнаўляльным, і ў ім розніца паміж веданнем свайго проксі і здагадкамі пра яго.