Чаще всего с прокси в терминале путают одну вещь: задали переменную среды, а потом удивляются, почему часть трафика идет напрямую. В командной строке важно сначала понять уровень настройки — текущая сессия, конкретная утилита или системный стек — и уже потом прописывать адрес, порт и авторизацию.

Где это реально нужно

Настройка прокси в командной строке обычно нужна не ради самой команды, а ради сценария. Например, нужно проверить сайт из другой сети, прогнать SEO-мониторинг, подключить серверный парсер к внешнему API, протестировать локализацию или разделить рабочий трафик по разным IP.

В таких задачах прокси часто настраивают прямо в shell, в конфиге конкретной утилиты или на уровне системного стека. И это три разных способа, которые ведут себя по-разному.

Главное правило: настройка прокси в терминале не означает, что через него автоматически пойдет весь трафик устройства. Обычно она влияет либо на текущую сессию, либо на конкретную программу, либо на отдельный системный компонент.

Если нужно настроить быстро

Для большинства CLI-задач на Linux и macOS достаточно переменных среды http_proxy, https_proxy, all_proxy и no_proxy. На Windows для многих консольных программ подходят переменные окружения в CMD или PowerShell, а для части системных служб используется отдельный стек WinHTTP.

Если задача разовая, удобнее передать прокси флагом конкретной программы, например в curl. Если задача постоянная, настройки переносят в профиль shell, конфиг утилиты или системные параметры.

  • Уточните у поставщика адрес прокси, порт, протокол и способ авторизации.
  • Проверьте, нужен ли вам HTTP/HTTPS-прокси или SOCKS5.
  • Определите область действия: одна команда, одна программа, текущая сессия или весь системный компонент.
  • Сразу продумайте список исключений для локальных адресов и внутренних доменов.
  • После настройки проверьте не только доступность, но и то, что трафик действительно идет через прокси.

Мобильные прокси России от 590 ₽ с ротацией

Отслеживайте, меняйте, переключайте и группируйте прокси в одном месте.

Перейти в личный кабинет

Что именно вы настраиваете: 4 уровня

Под одним запросом «настройка прокси в командной строке» скрываются разные механики. Ниже — самая полезная классификация с практической точки зрения.

Уровень На что влияет Когда использовать Ограничение
Переменные среды Текущий shell и дочерние процессы Разовые задачи, CI, серверные скрипты Работает только в программах, которые читают эти переменные
Флаг конкретной утилиты Один запуск команды Точный и безопасный тест без изменения окружения Нужно знать синтаксис каждой программы
Конфиг приложения Одна конкретная программа Git, npm, apt, pip и другие рабочие инструменты Каждая утилита хранит настройки по-своему
Системный стек Отдельные службы или системные сетевые компоненты Windows-службы, GNOME, macOS network services Не все приложения подчиняются системной настройке

Отсюда и типичная ошибка: прокси прописали в shell, а потом проверяют браузер или другой процесс, который этот shell вообще не наследует.

Как выглядит адрес прокси и что в нем важно

В командной строке прокси обычно задают в виде URL: http://HOST:PORT, http://LOGIN:PASSWORD@HOST:PORT или socks5://HOST:PORT. Если есть авторизация, логин и пароль часто встраиваются прямо в адрес, но это не всегда лучший вариант с точки зрения безопасности.

Особенно внимательно смотрите на схему в начале строки. Если утилита ожидает SOCKS5, а вы передали HTTP-прокси, соединение просто не поднимется или начнет вести себя непредсказуемо.

HTTP и HTTPS в названии переменной — не всегда про тип самого прокси

Это важный нюанс. Переменная https_proxy часто означает «прокси для обращений к HTTPS-ресурсам», а не обязательно «сам прокси доступен по HTTPS». На практике многие программы отправляют HTTPS-трафик через обычный HTTP-прокси с методом CONNECT.

Из этого следует простое правило: схему адреса и поддерживаемый протокол лучше проверять по документации конкретной программы и у самого поставщика прокси.

SOCKS5 и DNS: почему часто нужен именно socks5h

Если вы работаете не с HTTP-прокси, а с SOCKS5-прокси, важно понимать, где будет разрешаться имя хоста. У части клиентов схема socks5:// означает локальный DNS-резолвинг, а socks5h:// — резолвинг на стороне прокси.

На практике это всплывает в curl и совместимых библиотеках. Если задача чувствительна к географии DNS или вы не хотите локальный резолвинг, проверяйте, поддерживает ли ваша утилита вариант socks5h.

Linux и macOS: настройка через переменные среды

Это самый частый путь на серверах и в автоматизации. Он прост, прозрачен и подходит для большого числа CLI-инструментов: curl, wget, часть Python- и Node.js-утилит, некоторые пакетные менеджеры и скрипты.

На текущую сессию shell

Ниже базовый набор для bash, zsh и совместимых оболочек. Он действует только в текущем окне терминала и в процессах, которые вы запустите из него.

export http_proxy="http://HOST:PORT"
export https_proxy="http://HOST:PORT"
export all_proxy="socks5h://HOST:PORT"
export no_proxy="localhost,127.0.0.1,::1,.local"

Если нужна авторизация, она обычно добавляется в URL:

export http_proxy="http://LOGIN:PASSWORD@HOST:PORT"
export https_proxy="http://LOGIN:PASSWORD@HOST:PORT"

Сбросить настройки для текущей сессии можно так:

unset http_proxy https_proxy all_proxy no_proxy

Для Unix-подобных систем безопаснее в первую очередь использовать нижний регистр. Некоторые программы читают оба варианта, но у curl есть известное исключение: переменная HTTP_PROXY в верхнем регистре намеренно игнорируется.

Сделать настройку постоянной

Если прокси нужен регулярно, переменные добавляют в профиль оболочки, например в ~/.bashrc, ~/.zshrc или файл окружения, который подхватывает ваш shell. Пример строк для профиля:

export http_proxy="http://HOST:PORT"
export https_proxy="http://HOST:PORT"
export no_proxy="localhost,127.0.0.1,::1,.local"

После изменения профиля нужно либо открыть новый терминал, либо перечитать конфиг. Но и здесь есть ограничение: системные службы, контейнеры и фоновые процессы могут жить в другом окружении и эти переменные не унаследуют.

Как посмотреть текущие значения

env | grep -i proxy

Это быстрый способ понять, не осталась ли старая переменная в окружении. В реальной диагностике это экономит много времени, особенно когда разные скрипты накладывают настройки друг на друга.

Когда лучше задать прокси прямо в команде

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

curl

Для быстрой проверки прокси curl удобнее всего. Он явно показывает, какой прокси использован, и умеет подробный вывод.

curl --proxy "http://HOST:PORT" "https://TARGET"

curl --proxy "http://LOGIN:PASSWORD@HOST:PORT" "https://TARGET"

curl --proxy "socks5h://HOST:PORT" "https://TARGET"

curl -v --proxy "http://HOST:PORT" "https://TARGET"

Ключевой момент для SOCKS: если нужен DNS через прокси, используйте именно socks5h://, а не просто socks5://.

Git, npm, pip, apt и другие консольные инструменты

У части программ есть собственный конфиг, и это надежнее, чем глобальные переменные среды. Так проще избежать ситуации, когда один и тот же shell неожиданно влияет на весь набор утилит.

Инструмент Разовая настройка Постоянная настройка Что учесть
Git Через переменные среды или локальный config git config --global http.proxy "http://HOST:PORT" Для HTTPS-запросов часто настраивают отдельно https.proxy
npm Через переменные среды npm config set proxy "http://HOST:PORT"
npm config set https-proxy "http://HOST:PORT"		 Проверьте, нет ли конфликта между env и .npmrc
pip pip --proxy "http://HOST:PORT" ... Через конфиг pip или переменные среды Если пароль со спецсимволами, лучше не хранить его в открытом виде
apt apt -o Acquire::http::Proxy="http://HOST:PORT/" ... Через файл конфигурации apt Синтаксис apt отличается от shell-переменных
wget Через переменные среды Через конфиг wget или env Следите за тем, какие переменные реально читает ваша версия

Для автоматизации это особенно важно. Один удачно прописанный конфиг Git или npm часто полезнее, чем глобальный прокси для всей сессии.

Windows: CMD, PowerShell и WinHTTP

На Windows есть минимум два уровня, которые часто путают. Первый — обычные переменные окружения для консольных приложений. Второй — WinHTTP, который используют некоторые службы и программы.

Переменные среды в CMD и PowerShell

Для утилит, которые читают proxy-переменные, достаточно задать их в текущем окне.

CMD:

set HTTP_PROXY=http://HOST:PORT
set HTTPS_PROXY=http://HOST:PORT
set ALL_PROXY=socks5://HOST:PORT

Сброс в CMD:

set HTTP_PROXY=
set HTTPS_PROXY=
set ALL_PROXY=

PowerShell:

$env:HTTP_PROXY="http://HOST:PORT"
$env:HTTPS_PROXY="http://HOST:PORT"
$env:ALL_PROXY="socks5://HOST:PORT"

Сброс в PowerShell:

Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY

Проверить текущие proxy-переменные можно так:

Get-ChildItem Env:*proxy*

Этого достаточно для многих сценариев разработки, QA и скриптов, особенно если инструмент собран на libcurl, Node.js, Python или похожем сетевом стеке.

WinHTTP: когда нужен системный уровень для служб

Если нужно настроить прокси не для shell, а для части системных служб Windows и приложений, которые используют WinHTTP, применяется netsh. Это уже другой слой и другой результат.

netsh winhttp show proxy
netsh winhttp set proxy proxy-server="HOST:PORT" bypass-list="localhost;127.*;<local>"
netsh winhttp reset proxy

Обычно такие команды запускают с повышенными правами. Важно понимать ограничение: настройка WinHTTP не равна настройке всех приложений Windows. Часть программ использует свой сетевой стек и на эти параметры не смотрит.

Системная настройка из терминала: Linux desktop и macOS

Иногда нужен не серверный shell, а системный прокси, только без ручного кликанья по интерфейсу. Тогда команды будут уже другими.

Ubuntu и другие GNOME-системы: gsettings

Для окружений на базе GNOME системные параметры можно менять из терминала через gsettings. Это полезно в тестовых стендах, удаленной настройке рабочих мест и скриптах для QA.

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host 'HOST'
gsettings set org.gnome.system.proxy.http port PORT
gsettings set org.gnome.system.proxy.https host 'HOST'
gsettings set org.gnome.system.proxy.https port PORT
gsettings set org.gnome.system.proxy.socks host 'HOST'
gsettings set org.gnome.system.proxy.socks port PORT
gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.1', '::1']"

Выключить системный прокси в GNOME можно так:

gsettings set org.gnome.system.proxy mode 'none'

Этот способ относится именно к GNOME-сессии. На сервере без графического окружения или в другой desktop-среде он может быть просто неактуален.

macOS: networksetup

На macOS системный прокси для конкретного сетевого сервиса настраивается через networksetup. Сначала полезно посмотреть точное имя сервиса, потому что это не всегда «Wi-Fi».

networksetup -listallnetworkservices
networksetup -setwebproxy "Wi-Fi" HOST PORT
networksetup -setsecurewebproxy "Wi-Fi" HOST PORT
networksetup -setsocksfirewallproxy "Wi-Fi" HOST PORT

Отключение обычно выполняют отдельно для каждого типа прокси:

networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxystate "Wi-Fi" off

Это уже системная настройка интерфейса, а не просто значение внутри одного терминального окна.

Как проверить, что трафик действительно идет через прокси

Факт успешного соединения сам по себе еще не доказывает, что используется нужный маршрут. Проверять лучше последовательно.

  1. Проверьте, видит ли программа сами настройки. Для Linux и macOS это обычно env | grep -i proxy, для Windows — просмотр переменных окружения или netsh winhttp show proxy.

  2. Сделайте тестовый запрос с подробным выводом. У curl для этого удобно использовать -v. По логам видно, был ли CONNECT, на какой HOST:PORT пошло соединение и не ушел ли запрос напрямую.

  3. Сверьте IP на стороне тестируемого сервиса или вашего собственного стенда. Если задача рабочая, самый надежный путь — смотреть логи вашего же приложения или тестового ресурса.

  4. Проверьте географию и тип IP отдельно от факта соединения. Для SEO-мониторинга, рекламной аналитики и региональных тестов важно не просто наличие прокси, а соответствие нужной сети.

  5. Если используете SOCKS5, отдельно проверьте DNS-поведение. Разница между socks5:// и socks5h:// может полностью изменить результат проверки.

Для региональных задач по России обычно заранее подбирают инфраструктуру под нужную зону. Если сценарий связан с локальной выдачей, рекламной проверкой или тестом доступности из РФ, удобнее использовать российские мобильные прокси с понятной географией.

Где такая настройка особенно полезна

Командная строка — это прежде всего рабочий инструмент, а не витрина. Настройка прокси здесь чаще нужна тем, кто автоматизирует процессы и хочет контролировать сетевую среду.

  • SEO-мониторинг. Проверка выдачи, индексации, доступности страниц и сниппетов из разных сетевых условий.
  • QA и разработка. Тестирование API, локализации, маршрутов, CDN-поведения, ответов сервера и региональных сценариев.
  • Парсинг открытых данных. Сбор публичной информации с учетом правил ресурса и ограничений нагрузки.
  • Рекламная аналитика. Проверка отображения посадочных страниц, редиректов, меток и серверных ответов.
  • Серверные задачи. Обновления пакетов, работа Git, загрузка зависимостей, интеграции с внешними API.

Если нагрузка распределенная и нужен контролируемый пул адресов, в таких сценариях чаще используют прокси с ротацией. Но и здесь важно понимать режим работы: для части задач нужна частая смена IP, а для API, авторизованных интеграций и длинных сессий — наоборот, более стабильный канал.

Частые ошибки при настройке

Большинство проблем укладывается не в «прокси не работает», а в пять конкретных категорий.

1. Настроили не тот уровень

Задали http_proxy в терминале и ждут, что через него пойдут пакетный менеджер системы, графический браузер и фоновая служба. Это не так. Сначала определите, какой именно процесс должен использовать прокси.

2. Перепутали HTTP-прокси и SOCKS5

Очень частая история в curl, Git и сторонних CLI-утилитах. Адрес выглядит похоже, но схема в начале строки решает всё. Программа должна поддерживать именно тот тип прокси, который вы ей передаете.

3. Ошибка в логине, пароле или кодировке спецсимволов

Если пароль содержит @, :, # и другие специальные символы, строка URL может разобраться неверно. В таком случае нужен корректно закодированный URL или другой способ передачи учетных данных, если его поддерживает клиент.

4. Неверный no_proxy

Список исключений часто пишут с пробелами, неправильными доменами или ожидают от него одинакового поведения во всех программах. На практике синтаксис и правила совпадения могут немного различаться.

5. Проверяют соединение, но не проверяют DNS-путь

Для HTTP-прокси и SOCKS5 поведение по DNS различается. Если критична география или нужен именно удаленный резолвинг, этот момент нельзя оставлять «по умолчанию».

Что учитывать по безопасности

Прокси видит как минимум метаданные соединения: ваш адрес до прокси, адрес самого прокси, время запросов и направление трафика. Дальше все зависит от протокола и от того, есть ли шифрование на уровне приложения.

Если вы идете к обычному HTTP-ресурсу через HTTP-прокси, содержимое запроса может быть доступно оператору прокси. Если речь про HTTPS-ресурс через CONNECT, прокси обычно видит факт подключения и адрес назначения, но не само содержимое TLS-сеанса.

Пароли в командной строке — отдельный риск. Они попадают в историю shell, могут засветиться в process list, логах CI или скриптах. Для постоянной эксплуатации безопаснее использовать менеджеры секретов, переменные окружения в защищенном контуре или отдельные конфигурационные файлы с ограниченными правами доступа.

Что проверить перед рабочим запуском

  • Какой именно тип прокси вы получили: HTTP, HTTPS или SOCKS5.
  • Нужна ли авторизация по логину и паролю или разрешение по IP.
  • Должен ли трафик идти через прокси только в одной утилите или во всей рабочей среде.
  • Нужен ли удаленный DNS, особенно для SOCKS5.
  • Есть ли список исключений для локальных адресов, внутренних API и служебных доменов.
  • Не конфликтуют ли переменные среды с конфигами Git, npm, pip, apt и других инструментов.
  • Где будут храниться учетные данные и кто получит к ним доступ.

Что в итоге запомнить

Настройка прокси в командной строке — это в первую очередь вопрос области действия. Для разовых тестов лучше использовать флаг конкретной команды. Для ежедневной работы на сервере — переменные среды или конфиг программы. Для системных служб и desktop-окружения — отдельные системные команды вроде netsh, gsettings или networksetup.

Если держать в голове три вещи — уровень настройки, тип прокси и DNS-поведение — большая часть ошибок исчезает еще до первого запроса.

Что еще спрашивают по теме

Что такое настройка прокси в командной строке простыми словами?

Это способ направить сетевые запросы консольной программы или системного компонента через промежуточный сервер без использования графического интерфейса. Обычно для этого задают переменные среды, передают флаг самой утилите или меняют системный сетевой стек через специальные команды.

Если задать прокси в терминале, он повлияет на весь компьютер?

Обычно нет. Переменные среды чаще всего действуют только в рамках текущей shell-сессии и процессов, запущенных из нее. Чтобы изменить поведение системы шире, используют отдельные системные механизмы: WinHTTP в Windows, gsettings в GNOME, networksetup в macOS или конфиги конкретных служб.

Чем отличается HTTP-прокси от SOCKS5 в консольных инструментах?

HTTP-прокси работает на уровне HTTP и чаще используется для веб-запросов, API и пакетных менеджеров. SOCKS5 универсальнее на транспортном уровне и подходит для большего числа приложений, если клиент умеет с ним работать. Важно помнить про DNS: у SOCKS5 локальный и удаленный резолвинг могут включаться по-разному.

Почему curl иногда не реагирует на HTTP_PROXY?

У curl есть известная особенность: переменная HTTP_PROXY в верхнем регистре может игнорироваться. На Unix-подобных системах надежнее задавать http_proxy в нижнем регистре. Остальные переменные окружения тоже лучше проверять явно, а при диагностике использовать curl -v.

Как понять, что запрос реально пошел через прокси, а не напрямую?

Нужно смотреть не только на успешный ответ. Проверьте текущие переменные окружения или системные параметры, выполните запрос с подробным логом и сравните IP или логи на стороне вашего тестового ресурса. Для SOCKS5 отдельно убедитесь, что DNS ведет себя так, как вы ожидаете.

Можно ли хранить логин и пароль от прокси прямо в команде?

Технически можно, но в постоянной работе это не лучший вариант. Такие данные могут попасть в историю shell, скрипты, логи CI и список процессов. Для рабочих стендов и командной эксплуатации безопаснее использовать секреты окружения, защищенные конфиги и ограничение прав доступа к ним.

Когда в CLI-задачах имеет смысл ротация IP?

Ротация полезна там, где запросы идут сериями и нужно распределить нагрузку между разными адресами: SEO-мониторинг, проверка региональной выдачи, тесты доступности, сбор открытых данных. Но для длинных авторизованных сессий, серверных интеграций и части API чаще удобнее более стабильный IP без частой смены.