curl не може да ја прочита вашата PAC-датотека: предајте го проксито

Адресата на PAC-датотеката и крајната точка на проксито изгледаат заменливи во конфигурациска датотека, но не се. Едното е програма за политика што мора да се оцени за секој URL; другото е домаќин и порта што прима врски. curl го разбира само второто. Предавањето PAC-адреса на --proxy е категорична грешка што пропаѓа на збунувачки начин, обично по долго чекање на CONNECT кон веб-сервер.

Што е всушност секое од нив

Тоа јасно го кажува често поставуваните прашања за 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-патот до проксито. Токму тој запис го прави следното барање повторливо и ја прави разликата меѓу познавањето на вашето прокси и нагаѓањето за него.