Первый раз я настраивал прокси на Ubuntu в 2016-м и убил на это три часа. Не потому что сложно. Просто настройка живет в пятнадцати разных местах, и каждая программа читает только своё. Прописал http_proxy в терминале - браузер поехал через прокси, а apt спокойно тянет пакеты напрямую. Настроил apt - Docker качает образы мимо. Ситуация знакомая.
За годы собралась карта мест, куда реально надо зайти, чтобы трафик пошел как надо. Ниже - рабочий порядок, которым сам пользуюсь на Ubuntu, Debian и паре серверов на AlmaLinux. Без магии, только то, что проверял руками и на чем ломался не раз.
Переменные окружения - база, но половина программ их игнорирует
Самый очевидный уровень - переменные оболочки. Работают для curl, wget, большинства CLI-скриптов, некоторых языковых рантаймов. Задаются на лету или глобально в /etc/environment, чтобы подхватывали все пользователи и сервисы.
Ключей несколько: http_proxy, https_proxy, ftp_proxy и no_proxy. Регистр важен, многие инструменты читают оба варианта, некоторые только нижний. no_proxy - отдельная история: туда через запятую вбиваете адреса, которые должны идти напрямую. Локальные сети, внутренние сервисы, адреса вашего же сервера. Забыли про no_proxy - получите странные таймауты при обращении к localhost и зависшие healthcheck у сервисов.
Формат простой: схема://[юзер:пароль@]хост:порт. Для HTTP-прокси с авторизацией в адресе часто пишут креды, но так делать не стоит в скриптах и конфигах, которые лежат в репозитории. Лучше через отдельные переменные или менеджер секретов.
Подводный камень номер один: sudo. Когда вы делаете sudo apt update, оболочка переключается на root и переменные пользователя часто теряются. Именно поэтому настройка в .bashrc не спасает пакетный менеджер. Учитывайте это.
GNOME и KDE - отдельный слой для графики
Графические приложения в большинстве своем не смотрят на переменные оболочки. Chrome, Firefox, Thunderbird, мессенджеры читают настройки десктоп-окружения. В GNOME это делается через gsettings, в KDE - через системные настройки.
Для GNOME три команды: включаете manual-режим, задаете хост и порт для http и https, при необходимости добавляете список исключений. После этого Chrome и большинство GTK-приложений подхватят настройки сами. Firefox, кстати, живет своей жизнью и в некоторых сборках игнорирует системный прокси, там лучше настроить внутри браузера вручную.
В KDE все через графический интерфейс: Параметры системы, раздел сети, прокси. Работает предсказуемо, но запомните: настройка привязана к пользователю. Зашли под другим аккаунтом - прокси снова нет.
apt, dnf и пакетные менеджеры живут отдельно
Пакетные менеджеры не читают ни переменные оболочки, ни настройки десктопа. У каждого свой конфиг.
apt в Debian и Ubuntu настраивается через файл в /etc/apt/apt.conf.d/. Создаете новый файл, например 95proxies, и прописываете строки Acquire::http::Proxy и Acquire::https::Proxy с адресом прокси. После этого apt update и apt install ходят через прокси независимо от того, что у вас в терминале. Проверить легко: apt update и смотрите, откуда реально тянутся индексы.
dnf и yum на RHEL-подобных системах настраиваются в /etc/dnf/dnf.conf. Там же отдельные ключи для юзера и пароля, если прокси с авторизацией. yum на старых системах читает /etc/yum.conf с теми же параметрами.
pacman на Arch - в /etc/pacman.conf, секция про XferCommand или прямо через переменные окружения в профиле root. Snap и Flatpak тоже не читают переменные пользователя, у них свои команды настройки: snap set system proxy.http и proxy.https, для Flatpak - переменные в сессии.
git, npm, pip и инструменты разработчика
Отдельная боль - инструменты, которые тянут зависимости. Каждый со своим конфигом, и каждый по умолчанию игнорирует системные настройки.
git настраивается двумя командами: git config --global http.proxy и https.proxy. Отдельно, если нужно, через --unset снимаете. Есть нюанс с локальными репозиториями и SSH-клонами - там работает отдельная настройка через ProxyCommand в ~/.ssh/config, но это уже про SSH-туннели, не про HTTP-прокси.
npm и yarn читают свои конфиги. npm config set proxy и https-proxy, для yarn - yarn config set. pip настраивается через ~/.pip/pip.conf или pip config, секция [global] с параметром proxy. Если этого не сделать, pip install будет висеть на таймауте, а вы будете думать, что упал PyPI.
Maven, Gradle, Composer - у каждого свой файл настроек и свой синтаксис. Общее правило: если инструмент ставится отдельно и управляет зависимостями, у него почти наверняка есть собственный конфиг прокси. Читайте документацию, не полагайтесь на переменные.
systemd и сервисы - забытый уровень
Самое коварное место. Сервисы, запущенные через systemd, не наследуют переменные вашей оболочки. Демон работает в своей среде, и если ему нужен прокси, прописывать надо в юните или drop-in файле.
Делается через /etc/systemd/system/имя-сервиса.service.d/proxy.conf с секцией [Service] и строками Environment="HTTP_PROXY=..." и Environment="HTTPS_PROXY=...". После правки systemctl daemon-reload и systemctl restart сервиса. Без daemon-reload изменения не применятся, и вы полчаса будете гадать, почему ничего не работает.
Типичный кейс: агент мониторинга, который должен отдавать метрики наружу через корпоративный прокси. Или воркер, который тянет задачи из внешнего API. Без drop-in файла он просто не выйдет в сеть, и в логах будет глухой таймаут.
Docker и контейнеры - три уровня настройки
С Docker сложнее, потому что уровней сразу три. Первый - клиент docker, который должен качать образы. Второй - сам демон dockerd, у которого своя среда. Третий - контейнеры, которым прокси нужен внутри.
Клиент настраивается через ~/.docker/config.json, секция proxies с ключами httpProxy, httpsProxy и noProxy. Это работает для docker pull и docker build на клиентской машине.
Демон настраивается через systemd drop-in для docker.service, аналогично тому, что выше. Прописываете Environment с переменными, перезапускаете демон. Без этого docker pull может ходить напрямую, даже если клиент настроен, потому что за скачивание образов отвечает демон. На Reddit эта ошибка всплывает постоянно: пользователи правят конфиг клиента и удивляются, почему docker pull идет мимо.
Внутри контейнера прокси задается через build-args при сборке или через переменные в docker run. Для docker-compose - в секции environment или через файл .env. Не забудьте про no_proxy для связи между контейнерами в одной сети, иначе они начнут ходить друг к другу через прокси и получат отказ.
SOCKS5 - когда нужен именно он
HTTP-прокси работает на уровне приложений и понимает только HTTP-трафик. SOCKS5 работает ниже и прогоняет через себя любой TCP-трафик. Разница принципиальная, если вам нужно, например, гонять через прокси не только браузер, но и SSH-соединения, базы данных, кастомные протоколы.
На практике SOCKS5 часто поднимают через SSH-туннель на собственном VPS: ssh -D 1080 user@server, и на локальной машине появляется локальный SOCKS5 на порту 1080. Дальше направляете в него приложения через настройки или через proxychains. Последний перехватывает системные вызовы и заставляет любую программу идти через прокси, даже если она об этом не подозревает. Удобно для отладки и для старых утилит без поддержки прокси.
Важный нюанс SOCKS5: часть приложений не умеет авторизацию в нем, только в HTTP. И часть не умеет разрешать DNS через прокси, из-за чего утечка запросов идет через локальный резолвер. Если это критично, ищите опцию remote DNS или используйте прокси, который делает это по умолчанию.
Когда выбираете, куда направить трафик - на свой VPS, на корпоративный узел или на публичный сервис - смотрите на репутацию и стабильность. Для рабочих задач я обычно беру из каталога https://3seller.com/proxy, там есть и HTTP, и SOCKS5 под разные сценарии, с понятными параметрами по географии и скорости.
Как проверить, что все реально работает
Простая проверка - curl -I https://ifconfig.me и посмотреть, какой IP вернулся. Если ваш собственный, значит трафик идет напрямую. Если адрес прокси, все ок.
Второй уровень: проверьте каждый инструмент отдельно. apt update, docker pull, git clone, npm install. Не полагайтесь на один тест, потому что настройки разбросаны по разным местам и половина может молча игнорироваться.
Третий уровень: смотрите логи прокси-сервера. Если у вас свой узел, там видно, какие запросы пришли и откуда. Это самый надежный способ понять, что происходит на самом деле, а не что вы думаете, что происходит.
Отдельно проверьте no_proxy. Откройте localhost в браузере, обратитесь к внутреннему API. Если вдруг начало таймаутить там, где раньше работало, почти наверняка вы зацепили локальный трафик проксированием.
Ошибки, которые я видел чаще всего
Первая - путать уровни. Настроить переменные в терминале и удивляться, что apt или Docker не подхватили. Это разные слои, и настраивать надо каждый отдельно.
Вторая - забыть про sudo. Пользователь настроил, а команды с sudo идут мимо. Либо наоборот: root настроил, а пользовательские приложения не видят.
Третья - игнорировать no_proxy. Половина странных багов с внутренними сервисами именно отсюда. Локальные адреса, подсети, домены компании - все это должно быть в исключениях.
Четвертая - пропустить daemon-reload после правки systemd. Файл лежит, а сервис работает по старой конфигурации. Всегда reload и restart, иначе результат непредсказуем.
Пятая - тащить креды в открытом виде в конфиги, которые потом попадают в git. Используйте отдельные файлы с ограниченными правами или менеджеры секретов. Банально, но на этом ловятся постоянно.
Шестая - не проверять после каждого шага. Настроили apt, проверили. Настроили Docker, проверили. Иначе в конце непонятно, что именно сломалось и на каком уровне.
Что делать дальше
Начните с одного уровня и доведите до рабочего состояния. Для сервера это обычно apt и systemd-сервисы. Для десктопа - переменные окружения плюс настройки GNOME. Docker и инструменты разработчика добавьте, когда база уже стабильно работает.
Если нужен сам прокси - держите под рукой каталог https://3seller.com/proxy. Там можно подобрать вариант под задачу: для парсинга, для работы с API, для защиты трафика в публичной сети. Главное - не пытайтесь настроить все сразу. По одному уровню за раз, с проверкой после каждого шага. Тогда через час у вас будет рабочая конфигурация, а не пятнадцать недонастроенных мест.