Как настроить прокси на Linux: через терминал, систему и отдельные приложения

С чего начать, чтобы не переделывать настройку дважды

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

Поэтому первый вопрос не «где ввести IP и порт», а «какой именно трафик нужно проксировать». Для SEO-мониторинга, проверки рекламы, QA и парсинга открытых данных это критично: браузер может работать через прокси, а curl или apt — нет.

Какие данные нужны для подключения

Минимальный набор всегда один и тот же: IP-адрес или домен прокси, порт, а при необходимости — логин и пароль. Дальше начинается разница по протоколам и синтаксису.

Формат адреса для HTTP, HTTPS и SOCKS5

Для HTTP-прокси адрес обычно выглядит так:

http://user:password@proxy.example.com:3128

Для SOCKS5 — так:

socks5://user:password@proxy.example.com:1080

Если авторизации нет, часть user:password@ просто убирается.

Частая путаница: переменная https_proxy нередко содержит адрес вида http://proxy:port. Это не ошибка. Такой синтаксис означает, что клиент подключается к самому прокси по HTTP, а уже HTTPS-сайт открывает через метод CONNECT. У многих Linux-программ это нормальное поведение.

Пароль со спецсимволами

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

Отдельно учитывайте, что хранение учетных данных в открытом виде в командах и конфигурационных файлах — не лучшая практика. Для рабочих серверов лучше ограничивать права доступа к таким файлам и не оставлять секреты в истории shell.

Базовая настройка через переменные окружения

Если вам нужно быстро понять, работает ли прокси вообще, начните именно с переменных окружения. Это самый простой способ настроить прокси на Linux для терминала, скриптов и части консольных утилит.

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

Для HTTP- и HTTPS-трафика достаточно задать переменные в текущем shell:

export http_proxy="http://user:password@proxy.example.com:3128"
export https_proxy="http://user:password@proxy.example.com:3128"
export no_proxy="localhost,127.0.0.1,::1,.local"

Если приложение понимает SOCKS5 через переменную общего прокси, обычно используют all_proxy:

export all_proxy="socks5://user:password@proxy.example.com:1080"

Для части инструментов на базе libcurl полезен вариант socks5h://: в таком случае имя хоста разрешается через прокси, а не локально. Это важно, если вы тестируете отображение сайта из другой сети или хотите избежать локального DNS-разрешения там, где программа его поддерживает.

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

Если прокси нужен каждый день, добавьте переменные в файл профиля пользователя. На практике чаще всего используют ~/.profile, ~/.bashrc или конфигурацию конкретного shell. Какой файл сработает, зависит от того, как именно запускается сессия: интерактивно, через терминал эмулятора или по SSH.

export http_proxy="http://user:password@proxy.example.com:3128"
export https_proxy="http://user:password@proxy.example.com:3128"
export no_proxy="localhost,127.0.0.1,::1,.corp.local"

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

Для всех пользователей через /etc/environment

Когда нужна базовая общая настройка, часто используют /etc/environment. В этом файле переменные записываются без слова export.

http_proxy="http://proxy.example.com:3128"
https_proxy="http://proxy.example.com:3128"
no_proxy="localhost,127.0.0.1,::1,.local"

Этот вариант удобен для рабочих станций, но не стоит считать его универсальным. Сервисы, запущенные через systemd, могут не унаследовать переменные пользователя. А программы с собственной логикой сети могут игнорировать их полностью.

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

Как настроить прокси на Linux в графической среде

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

Через системные параметры

В GNOME, KDE и производных названия пунктов могут немного отличаться. На рабочих столах с минимальной оболочкой часть GUI-приложений вообще не получает общую прокси-конфигурацию и требует ручной настройки внутри себя.

Через терминал в GNOME

Если на машине GNOME и нужен воспроизводимый способ без ручного прокликивания, можно задать параметры командой gsettings:

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

Для отключения системного профиля в GNOME достаточно вернуть режим:

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

Если у прокси есть авторизация, часть окружений умеет хранить ее отдельно, а часть просит логин и пароль уже при подключении приложения. Из-за различий между версиями и сборками этот момент лучше проверять на вашей системе отдельно.

Настройка отдельных программ: здесь чаще всего и прячется проблема

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

curl

curl удобен для проверки, потому что позволяет быстро переключать тип прокси и не зависит от GUI.

curl -I https://example.com
curl --proxy http://user:password@proxy.example.com:3128 -I https://example.com
curl --proxy socks5h://proxy.example.com:1080 -I https://example.com

Если вы используете SOCKS5-прокси для проверки геозависимого контента или удаленного тестирования, вариант socks5h обычно предпочтительнее обычного socks5: имя хоста резолвится на стороне прокси, а не локально.

wget

wget обычно берет настройки из переменных окружения или из ~/.wgetrc. Простейший пользовательский конфиг выглядит так:

use_proxy = on
http_proxy = http://proxy.example.com:3128/
https_proxy = http://proxy.example.com:3128/

Для стандартного GNU Wget в типовом сценарии речь идет именно о HTTP/HTTPS-прокси. Если в вашей задаче нужен SOCKS, заранее проверьте, понимает ли его конкретная версия или придется использовать другой клиент.

Git

Для корпоративной разработки и CI/CD часто достаточно указать прокси прямо в Git:

git config --global http.proxy http://proxy.example.com:3128
git config --global https.proxy http://proxy.example.com:3128

Отключение делается так:

git config --global --unset http.proxy
git config --global --unset https.proxy

Если репозитории доступны, а сторонние хосты нет, проблема может быть не в Git, а в правилах маршрутизации или в том, что системный сертификатный store и прокси-сценарий настроены отдельно.

APT и DNF

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

Для APT обычно создают отдельный файл в /etc/apt/apt.conf.d/:

Acquire::http::Proxy "http://proxy.example.com:3128/";
Acquire::https::Proxy "http://proxy.example.com:3128/";

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

Для DNF на системах семейства Fedora/RHEL параметры задаются в /etc/dnf/dnf.conf:

[main]
proxy=http://proxy.example.com:3128
proxy_username=myuser
proxy_password=mypassword

APT и DNF чаще всего ожидают именно HTTP-прокси. Если поставщик выдал только SOCKS5, заранее проверьте совместимость под ваш пакетный менеджер и версию дистрибутива.

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

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

Отдельно важно понимать, что ping не помогает проверить прокси-настройку. ICMP-запросы обычно не идут через HTTP- или SOCKS-прокси, поэтому успешный ping ничего не говорит о правильности конфигурации.

Типичные ошибки при настройке прокси на Linux

Ожидание, что одна настройка покроет все программы

Это самая частая ошибка. Переменные окружения хорошо работают для shell-сценариев, но не обязаны управлять GUI, пакетными менеджерами, демонами и контейнерами.

Неверное понимание переменной https_proxy

Многие думают, что для HTTPS обязательно нужен адрес вида https://proxy.... На практике у большого числа Linux-инструментов рабочий формат — http://proxy:port и CONNECT до целевого HTTPS-сайта. Если перепутать этот момент, легко получить ложное ощущение, что прокси «не подходит под HTTPS».

Локальное DNS-разрешение там, где ожидался прокси

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

Пароль со спецсимволами вставлен как есть

Символы @ и : внутри строки подключения часто ломают синтаксис. В результате кажется, что прокси «не авторизует», хотя проблема в формате URL.

Забыли исключения no_proxy

Если не добавить localhost и внутренние адреса, можно неожиданно сломать доступ к локальным сервисам, внутренним registry, корпоративным API и панелям администрирования. Для рабочих станций и серверов это не мелочь, а обычная причина ложных инцидентов.

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

Прокси — это не просто транспорт. Он видит как минимум факт подключения, время, объем трафика и целевой адрес или хост в пределах своего протокола. Если соединение к сайту идет по обычному HTTP, содержимое запроса может быть видно прокси полностью. Если используется HTTPS, содержимое защищено между клиентом и сайтом, но метаданные соединения остаются заметны.

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

Какой способ настройки выбрать под задачу

Если нужен быстрый запуск скрипта, берите переменные окружения. Если это офисный ноутбук и важны браузер с GUI-приложениями — начните с системного профиля рабочего стола. Если речь про CI, сервер, пакетный менеджер или демон, почти всегда надежнее отдельная настройка самого приложения или сервиса.

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

Хороший рабочий принцип для Linux: сначала настраиваем прокси в самой программе, которая критична для задачи, потом — общесистемные параметры. Не наоборот.

Что стоит запомнить

Настроить прокси на Linux можно несколькими способами, и ни один из них не покрывает все случаи автоматически. Для терминала и скриптов чаще всего достаточно http_proxy, https_proxy и no_proxy. Для графической среды нужен системный профиль рабочего стола. Для APT, DNF, Git и других рабочих инструментов надежнее отдельная настройка внутри приложения.

Если после настройки «что-то работает, а что-то нет», это обычно не сбой Linux и не проблема самого прокси. Чаще всего виноват уровень применения конфигурации: пользователь, shell, GUI, служба или конкретная программа.

Частые вопросы по настройке прокси на Linux

Какой способ настройки прокси на Linux самый универсальный?

Самого универсального способа нет. Для терминальных утилит и скриптов удобнее всего переменные окружения. Для рабочего стола — системные параметры GUI. Для пакетных менеджеров, Git и фоновых сервисов надежнее отдельная конфигурация программы. Именно смешение этих уровней чаще всего и вызывает ошибки.

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

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

Почему curl работает через прокси, а apt — нет?

Потому что это разные программы с разной логикой чтения настроек. curl часто берет параметры из переменных окружения или ключа командной строки. APT в реальной работе надежнее настраивать через собственный файл в /etc/apt/apt.conf.d/. Если рассчитывать только на пользовательский shell, пакетный менеджер может его просто не унаследовать.

Как отключить прокси на Linux без перезагрузки?

Если прокси задан только в текущем shell, достаточно удалить переменные командой unset http_proxy https_proxy all_proxy no_proxy. Если использовались файлы профиля, изменения вступят в силу после новой сессии или перечитывания конфигурации. В GNOME можно переключить режим на none через gsettings или через системные параметры.

Нужно ли настраивать no_proxy?

Почти всегда да. Без no_proxy легко сломать доступ к localhost, внутренним доменам, локальным registry и служебным интерфейсам. Минимальный набор обычно включает localhost, 127.0.0.1 и ::1. Остальные адреса зависят от вашей инфраструктуры и того, какие сервисы не должны уходить через прокси.

Влияет ли прокси-настройка на DNS-запросы?

Зависит от приложения и типа прокси. Одни клиенты сначала разрешают домен локально, а потом подключаются через прокси. Другие умеют передавать резолвинг на сторону прокси, как это бывает с socks5h в части инструментов. Если для вас критична география ответа или сетевое окружение, этот момент нужно тестировать отдельно.

Подходит ли системная настройка Linux для браузерных профилей и командной работы?

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