☰

OSX El Capitan и http_proxy с определенным путем к proxypac

tag-icon • tag-icon macos http-proxy
OSX El Capitan и http_proxy с определенным путем к proxypac

Стандартная корпоративная среда, заставляющая клиентов проходить через прокси-сервер через proxypac. В OSX конфигурация имеет следующий формат:

http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

Пытаюсь подключиться через CLI для установки homebrew и использовал (пока) следующие параметры:

export http_proxy=http://www.proxy.server.name:8080/proxy_pac_path_to_package.pac

export http_proxy=http://www.proxy.server.name:8080

export http_proxy=http://myusername:[email protected]:8080/proxy_pac_path_to_package.pac

export http_proxy=http://myusername:[email protected]:8080

при этом специальные символы mypasswd отображаются в их шестнадцатеричном коде, а имя пользователя может быть представлено либо в «простой» форме, либо в виде полного пути AD, либо адреса электронной почты и т. д.

Ничего из вышеперечисленного не сработало. Есть идеи, что я могу упустить, из собственного опыта через неочевидные вещи?

решение1

Поскольку у меня нет доступа к вашей конкретной корпоративной среде, я не могу поставить точный диагноз, но первое, что я бы попробовал, это экспортировать https_proxyи all_proxyс тем же значением (обратите внимание, что у https_proxyможет не быть https:URL; у него есть то, что http_proxyесть). Ваши различные выборки значений были правильными для пробы (хотя я видел очень странные кодировки имени пользователя/пароля, поэтому я бы не стал это списывать со счетов). Я бы убедился, что Safari работает через прокси, и если вам нужно войти в прокси через Safari, вы это делаете. Если Safari не работает через прокси, то вероятность того, что Homebrew будет работать, по сути, нулевая.

В качестве второго варианта (хотя это вуду и может быть просто карго-культом) вы можете попробовать установить его вместо схемы на http:схему socks5:, в противном случае оставив остальную часть URL прежней. Я видел, что это работает, потому что некоторые прокси больше ориентированы на клиентов Windows и все еще имеют старый код, а из-за плохой истории взаимодействия между TCP-стеками версий Windows SOCKS был более надежным.

решение2

Невероятно!!! Огромный DUH с моей стороны: было открыто два окна iTerm одновременно - я делал экспорт http_proxy в одном, из CLI, и проверял подключение в другом (который запускал другой сеанс оболочки, конечно, без осведомленности об экспортированных переменных в том, в котором я вносил изменения)... не могу поверить, насколько это было глупо. Извините за весь шум... и спасибо @Trey за то, что предположил, что я не идиот :-)

Связанный контент