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 пътя до проксито. Този запис прави следващата заявка възпроизводима и той е разликата между това да познавате проксито си и да гадаете за него.