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 к прокси. Именно эта запись делает следующий запрос воспроизводимым, и в ней разница между знанием своего прокси и догадками о нём.