Обычно проблема выглядит так: браузер через прокси работает, а <code>composer install</code> зависает, не скачивает архивы или внезапно уходит в прямое подключение. У Composer это частая история, потому что в цепочке участвуют не только сам менеджер зависимостей, но и PHP, cURL, а иногда ещё Git. Ниже — практический разбор, как запустить Composer через SOCKS5-прокси без гаданий и где чаще всего ломается схема.
Когда Composer имеет смысл пускать через SOCKS5
Сценарий вполне рабочий, если вам нужно стабильно выводить сетевые запросы Composer через отдельный IP, тестировать сборки из другого сетевого окружения, разделять трафик CI/CD или проверять доступность пакетов и зеркал из определённой сети.
Для таких задач Composer через SOCKS5-прокси обычно настраивают на уровне переменных окружения. Это важный момент: в большинстве случаев прокси не прописывают в composer.json и не ищут для этого отдельную универсальную команду внутри Composer.
Практический вывод: если задача касается только загрузки зависимостей, вам нужен не «любой прокси», а предсказуемый маршрут для CLI-приложения. Для Composer важнее стабильность соединения и корректная работа HTTPS, чем частая ротация IP.
Как Composer использует прокси на практике
Composer сам по себе — это CLI-клиент для PHP. Когда вы запускаете composer install или composer update, он обращается к репозиториям пакетов, скачивает метаданные, архивы dist и, в некоторых случаях, вызывает внешние VCS-инструменты.
Именно поэтому путь трафика может разделяться:
- часть запросов идёт через сам Composer;
- часть — через PHP и расширение cURL, если оно используется в системе;
- часть — через Git, если пакет ставится из исходников, а не из архива.
Отсюда и главный подводный камень: даже если вы задали прокси для Composer, это не всегда означает, что git clone внутри той же установки пойдёт тем же маршрутом.
На каком уровне задаётся прокси
Для Composer прокси обычно задают через переменные окружения HTTP_PROXY и HTTPS_PROXY. В рабочих конфигурациях с поддержкой cURL этого часто достаточно и для SOCKS5, если в значении переменной указан соответствующий префикс схемы.
Но есть ограничение: результат зависит от версии Composer, сборки PHP и того, какой транспорт фактически используется на вашей машине. Если PHP работает без cURL или окружение жёстко завязано на HTTP-прокси, SOCKS5 через одни только переменные может не отработать так, как ожидается.
Мобильные прокси России от 590 ₽ с ротацией
Отслеживайте, меняйте, переключайте и группируйте прокси в одном месте.
Перейти в личный кабинетПочему для Composer чаще выбирают SOCKS5, а не HTTP-прокси
SOCKS5 работает на более низком уровне, чем HTTP-прокси, и обычно лучше подходит для смешанного трафика CLI-инструментов. В случае Composer это удобно, потому что рядом с HTTPS-загрузками могут участвовать и сторонние инструменты, которым нужен не только HTTP-сценарий.
Если коротко: HTTP-прокси хорош для простых веб-запросов, а SOCKS5 — для более гибкой маршрутизации приложений. Подробно различия между протоколами мы уже разбирали в материале про SOCKS5-прокси.
| Параметр | Что это значит для Composer |
|---|---|
| HTTP-прокси | Подходит для типовых веб-запросов, но может быть менее удобен, если в цепочке участвуют разные CLI-инструменты |
| SOCKS5 | Гибче для клиентских приложений и часто удобнее в смешанной среде Composer + Git + PHP cURL |
socks5:// | DNS-разрешение может зависеть от клиента и уйти локально |
socks5h:// | Обычно предпочтительнее: имя хоста разрешается на стороне прокси, что даёт более предсказуемый маршрут |
| Ротация IP | Для пакетного менеджера чаще мешает, чем помогает: загрузка зависимостей любит стабильную сессию |
Если выбирать схему адреса, для Composer и похожих CLI-задач на практике чаще берут socks5h://, а не просто socks5://. Причина простая: так меньше сюрпризов с DNS.
Что подготовить до настройки
- Адрес прокси-сервера
- Порт
- Логин и пароль, если включена авторизация
- Понимание, нужен ли именно
socks5h, а неsocks5 - Проверка, что в PHP доступен cURL, если вы рассчитываете на стандартную схему через переменные окружения
- Понимание, будут ли пакеты скачиваться как
distили из Git-репозиториев
Последний пункт многие пропускают. Если проект тянет зависимости из исходников, одной настройки Composer может оказаться мало — придётся отдельно посмотреть на конфигурацию Git.
Как настроить Composer через SOCKS5-прокси
Базовый принцип такой: вы задаёте переменные окружения для текущей сессии терминала, после чего запускаете Composer в этом же окружении. Так проще проверить результат и проще откатить настройки.
Linux и macOS
export HTTP_PROXY="socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"
export HTTPS_PROXY="socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="127.0.0.1,localhost"
composer diagnose
composer install -vvvЗдесь есть два практических нюанса. Первый: верхний и нижний регистр переменных иногда дублируют специально, потому что разные утилиты и обвязки в контейнерах могут смотреть на разные варианты. Второй: NO_PROXY полезен, если часть локальных адресов не должна идти через прокси.
Windows PowerShell
$env:HTTP_PROXY = "socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"
$env:HTTPS_PROXY = "socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"
$env:NO_PROXY = "127.0.0.1,localhost"
composer diagnose
composer install -vvvЕсли вы запускаете Composer в другой оболочке, переменные нужно задавать для неё отдельно. Смысл тот же: прокси должен оказаться в окружении того процесса, который реально выполняет сетевой запрос.
Если в логине или пароле есть спецсимволы
Символы вроде @, :, / и # в строке подключения часто ломают авторизацию. В таком случае их нужно URL-кодировать, иначе Composer или библиотека под ним могут неправильно разобрать адрес прокси.
Постоянная настройка в CI и на сервере
В CI/CD переменные лучше хранить в секрете пайплайна, а не в открытом скрипте сборки. Для выделенного сервера прокси можно задать на уровне пользователя или службы, но сначала полезно проверить схему на одной сессии терминала, а уже потом закреплять её постоянно.
Не храните логин и пароль от прокси в
composer.json, в истории shell-команд или в общедоступных скриптах развёртывания. Для серверов и командной работы безопаснее использовать переменные окружения и секреты CI.
Когда нужно отдельно настраивать Git
Если Composer скачивает пакет в виде архива dist, часто хватает его собственных сетевых настроек. Но если зависимость тянется из репозитория источников, сетевую работу уже выполняет Git, а не только Composer.
В таком случае полезно проверить, не уходит ли трафик Git в обход прокси. Для систем, где Git собран с поддержкой cURL, обычно используют такую схему:
git config --global http.proxy "socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"
git config --global https.proxy "socks5h://LOGIN:PASSWORD@PROXY_HOST:PROXY_PORT"Дальше снова запускают composer install -vvv и смотрят, на каком этапе исчезла ошибка. Если пакетный архив скачивается, а клонирование нет, проблема почти всегда в том, что прокси настроен только для Composer, но не для Git.
Как понять, что Composer действительно идёт через прокси
Самый практичный способ — запускать команды с повышенной подробностью и смотреть, на каком этапе происходит сбой. Команда composer diagnose помогает быстро отсеять грубые проблемы с сетью, TLS и конфигурацией. А режим -vvv показывает гораздо больше деталей при реальной установке пакетов.
Задайте переменные окружения в текущей сессии и не смешивайте сразу несколько способов настройки.
Запустите
composer diagnose. Если уже здесь появляются ошибки соединения, сначала разбирайте прокси, а не проект.Выполните
composer install -vvvилиcomposer update -vvv. Смотрите, где именно всё ломается: на метаданных, на скачивании архива или на шаге Git.Если проблема появляется только на пакетах из исходников, проверьте конфигурацию Git отдельно.
Если часть запросов всё равно идёт не туда, сравните
socks5иsocks5h. Для CLI-задач это часто решает проблему с DNS-маршрутом.
Полезный маркер: если после перехода на socks5h ошибка «не находится хост» исчезает, проблема была не в авторизации, а в том, как разрешалось доменное имя.
Где чаще всего спотыкаются
| Симптом | Частая причина | Что проверить |
|---|---|---|
| Composer не качает пакеты, но браузер работает | Прокси настроен для системы или браузера, но не для терминальной сессии | Есть ли HTTP_PROXY и HTTPS_PROXY именно в том shell, где запущен Composer |
| Метаданные загружаются, а дальше ошибка на Git | Composer идёт через прокси, а Git — напрямую | Настроены ли http.proxy и https.proxy в Git |
| Ошибка авторизации к прокси | Неверный логин/пароль или спецсимволы в строке подключения | Корректно ли закодированы спецсимволы |
| Хост не резолвится | Локальный DNS, хотя ожидался прокси-DNS | Используется ли socks5h:// вместо socks5:// |
| Подключение нестабильное | Слабый узел, высокая задержка, перегруженный прокси | Проверьте стабильность канала, а не только сам факт открытия соединения |
| После смены прокси часть запросов продолжает идти по старому пути | Настройки остались в другой оболочке, службе или кеше процесса | Перезапустите терминал, службу или job и проверьте окружение заново |
Ограничения, о которых лучше знать заранее
Composer через SOCKS5-прокси — это не универсальный «переключатель сети» для всей машины. Настройка может касаться только текущего процесса, только текущего пользователя или только той цепочки, где Composer реально использует cURL.
Ещё одно важное ограничение — ротация IP. Для парсинга или тестов ротационный маршрут может быть полезен, но для пакетного менеджера он чаще избыточен. Если IP меняется посреди загрузки или между последовательными запросами, стабильность только ухудшается. Поэтому для Composer логичнее обычный стабильный SOCKS5, а не прокси с ротацией.
Если нужен отдельный IP для серверной сборки, смотрите прежде всего на стабильность, задержку и предсказуемость маршрута. Для Composer это обычно важнее, чем агрессивная смена адресов.
Что прокси видит, а что нет
Если Composer скачивает зависимости по HTTPS, содержимое трафика защищено TLS между клиентом и целевым сервером. Но сам факт подключения, адрес назначения, время соединения и часть служебных метаданных прокси-узел всё равно видит.
Из этого следует простой вывод: бесплатный публичный прокси для рабочих сборок — плохая идея. Он может быть медленным, нестабильным и непрозрачным с точки зрения логов и обработки трафика. Для командной работы и CI лучше использовать предсказуемый узел с понятными условиями и поддержкой SOCKS5.
Кому такой сценарий подходит лучше всего
- разработчикам PHP, которым нужно разделить рабочие подключения по проектам или средам;
- командам CI/CD, где сборка должна идти через отдельный исходящий маршрут;
- QA-специалистам, проверяющим поведение сборки в другом сетевом окружении;
- агентствам и техспециалистам, которым важна управляемая сетевая схема без ручной перенастройки браузера.
Если задача именно в приложенческой гибкости, а не в веб-просмотре, SOCKS5 обычно оказывается практичнее обычного HTTP-прокси. Для похожих сценариев с CLI и смешанным трафиком это типичный выбор.
Главное по теме
Настроить Composer через SOCKS5-прокси можно, но успешный результат зависит не от одной строки с адресом, а от всей цепочки: Composer, PHP cURL, DNS-поведение и, при необходимости, Git. В большинстве случаев рабочая схема такая: задать HTTP_PROXY и HTTPS_PROXY со значением socks5h://..., проверить composer diagnose, затем запустить установку с -vvv.
Если всё равно не работает, не меняйте сразу пять параметров. Сначала разберите, кто именно падает: сам Composer, DNS, авторизация к прокси или вызванный Git. Такой пошаговый подход почти всегда быстрее, чем хаотичная правка настроек.
Что обычно спрашивают по этой теме
Поддерживает ли Composer SOCKS5 напрямую?
На практике Composer обычно запускают через SOCKS5 не отдельной внутренней опцией, а через переменные окружения с адресом прокси. Работоспособность зависит от версии Composer, PHP и используемого транспорта. В типовой конфигурации с cURL такая схема часто работает, но универсальной гарантии для любых окружений нет.
Почему лучше использовать socks5h, а не socks5?
socks5h обычно отправляет разрешение доменного имени на сторону прокси-сервера. Для Composer это полезно, когда нужно, чтобы и сам TCP-сеанс, и DNS-маршрут были согласованы. С обычным socks5 часть окружений может пытаться резолвить имя локально, из-за чего поведение становится менее предсказуемым.
Нужно ли что-то менять в composer.json?
Обычно нет. Прокси для Composer чаще задают на уровне окружения процесса, а не внутри файла проекта. Это удобнее с точки зрения безопасности и проще для командной работы: конфигурация сети не попадает в репозиторий и не мешает другим разработчикам.
Почему Composer ходит через прокси, а установка всё равно падает на отдельных пакетах?
Частая причина в том, что часть зависимостей скачивается не как архивы, а из репозиториев исходников. Тогда сетевую часть берёт на себя Git. Если прокси настроен только для Composer, а Git не знает о нём, установка обрывается именно на этих пакетах.
Подходит ли для Composer ротационный прокси?
Обычно это не лучший вариант. Для пакетного менеджера важнее стабильное соединение и предсказуемая загрузка зависимостей, чем частая смена IP. Ротация полезна в других сценариях, но для composer install и CI-сборок она чаще создаёт лишнюю нестабильность.
Какой тип прокси выбрать для Composer: HTTP или SOCKS5?
Если задача ограничена простыми веб-запросами, HTTP-прокси может быть достаточен. Но когда речь идёт о CLI-инструментах, смешанном трафике и связке Composer + Git, SOCKS5 обычно удобнее по совместимости. Выбор всё равно зависит от конкретной схемы сборки и того, как настроен ваш сервер или рабочая станция.
