Старые HTTP_PROXY_REQUEST_FULLURI в Composer и связанные обходы FULLURI больше не нужны и не используются в документированной реализации. Проигнорированный флаг не может исправить маршрут работающего клиента.

Для Composer в командной строке в оболочке POSIX экспортируйте поддерживаемые переменные прокси до вызова Composer из этой оболочки:

export http_proxy=http://proxy.example:8080
export https_proxy=http://proxy.example:8080

Предпочтительны имена в нижнем регистре. Оба значения могут начинаться с http://, когда сам прокси использует обычный HTTP; назначению HTTPS не требуется HTTPS-соединение с прокси. Замените пример endpoint на одобренный сервис. Для публичных загрузок пакетов, где допустим публичный посредник, выберите HTTP-кандидата из списка HTTP-прокси.

IDE или агенту сборки нужны значения в его собственной среде процесса. Изменение постоянной настройки позже не обновляет уже запущенный процесс.

Когда Composer работает вне CLI

Для HTTP-запросов вне контекста CLI Composer не использует http_proxy или HTTP_PROXY. Вместо этого он документирует CGI_HTTP_PROXY, что защищает от того, чтобы заголовки запроса принимались за доверенную конфигурацию прокси. Не копируйте решение для оболочки в веб-приложение и не берите настройки прокси из недоверенного запроса.

Прочитайте неудачную операцию

Неразрешённое имя прокси, отклонённое соединение, запрос 407 и ошибка сертификата указывают на разные этапы. Используйте первую значимую ошибку, а не применяйте старые обходы IPv6 или проверки сертификатов.

Если HTTP-загрузка в Composer работает, а зависимость через Git не проходит, проверьте отдельный процесс Git, его маршрут и его учётную запись. Это другой потребитель, чем успешная загрузка Composer.

Похожие статьи