Настройка прокси в терминале Linux и CI: пошаговый гайд для HTTP_PROXY, HTTPS_PROXY, NO_PROXY

Представьте: вы открываете терминал, вводите команду установки пакета, а в ответ тишина или ошибка соединения. Часто причина в том, что доступ в сеть идёт только через прокси-сервер, а система об этом не знает. Этот гайд научит вас настраивать прокси везде, где это нужно на Linux и в CI.

Введение: что вы получите и для кого этот гайд

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

Что именно вы получите:

• Рабочую настройку прокси в текущей сессии терминала.
• Постоянную настройку, которая переживёт перезагрузку.
• Правильную конфигурацию для apt, dnf, git, npm, pip, curl, wget, Docker.
• Работающие пайплайны CI в GitHub Actions и GitLab Runner.
• Понимание, как проверить, что трафик реально идёт через прокси.
• Навыки безопасного хранения пароля от прокси.

Для кого этот гайд: для начинающих системных администраторов, разработчиков и DevOps-инженеров, которые работают в среде с корпоративным прокси. Есть и элементы для продвинутых: тонкости systemd, ProxyCommand для SSH и маскирование секретов в CI.

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

Сколько времени потребуется: базовая настройка займёт около 15 минут. Полное прохождение гайда с настройкой всех инструментов и CI — примерно 60-90 минут. Не спешите, лучше делать вдумчиво.

Совет: держите этот гайд открытым в отдельном окне и выполняйте команды по очереди. Так вы точно не пропустите важный шаг.

Предварительная подготовка: адрес, порт, логин и правильный URL прокси

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

Где взять данные прокси

Обычно прокси предоставляет одна из следующих сторон:

• Системный администратор компании — если вы работаете в корпоративной сети. Попросите у него адрес, порт и данные для авторизации.
• Сервис аренды прокси — в личном кабинете обычно есть блок с настройками доступа.
• Ваш собственный сервер — если вы поднимали прокси самостоятельно, данные вы знаете.

Вам нужны четыре элемента: адрес (host), порт (port), логин (username) и пароль (password). Иногда логин и пароль не требуются — тогда прокси без авторизации.

Как собрать URL прокси

Прокси задаётся в виде единой строки — URL. Общий формат такой:

схема://логин:пароль@адрес:порт

Разберём на примере. Пусть адрес прокси — proxy.example.com, порт — 3128, логин — ivan, пароль — secret123. Тогда URL будет выглядеть так:

http://ivan:secret123@proxy.example.com:3128

Если авторизация не нужна, URL проще:

http://proxy.example.com:3128

Про схему: чаще всего используется схема http даже для доступа к HTTPS-сайтам. Это нормально — схема здесь означает протокол общения с самим прокси, а не с целевым сайтом. Иногда встречаются прокси со схемой https или socks5.

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

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

Решение — percent-encoding (процентное кодирование). Каждый проблемный символ заменяется на знак процента и его код в шестнадцатеричной системе.

Основные замены:

• Символ @ становится %40
• Символ : становится %3A
• Символ / становится %2F
• Символ # становится %23
• Символ ? становится %3F
• Символ пробел становится %20
• Символ % становится %25

Пример: если пароль p@ss:word, то в URL он должен выглядеть как p%40ss%3Aword. Тогда полный URL будет:

http://ivan:p%40ss%3Aword@proxy.example.com:3128

Совет: чтобы быстро закодировать пароль, используйте команду python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=''))" 'ваш_пароль'. Она выдаст готовую строку для вставки в URL.

⚠️ Внимание: никогда не вводите реальный пароль прямо в командной строке в открытом виде на общем компьютере — он попадёт в историю. О безопасном вводе поговорим отдельно в конце гайда.

✅ Проверка: у вас на руках должен быть один или несколько собранных URL прокси, где все спецсимволы в пароле закодированы. Запишите их в надёжное место, лучше в менеджер паролей.

Базовые понятия: переменные окружения, регистр и формат NO_PROXY

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

Что такое переменные окружения

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

Многие сетевые утилиты в Linux при запуске читают специальные переменные и, если находят их, автоматически направляют трафик через прокси. Самые важные из них:

• HTTP_PROXY — прокси для незашифрованных HTTP-запросов.
• HTTPS_PROXY — прокси для зашифрованных HTTPS-запросов.
• NO_PROXY — список адресов, к которым нужно ходить напрямую, минуя прокси.
• FTP_PROXY — прокси для протокола FTP, сейчас используется редко.
• ALL_PROXY — прокси для всех протоколов сразу, часто применяется для socks.

Разница http_proxy и HTTP_PROXY по регистру

Это тонкий, но важный момент. Linux различает регистр букв, поэтому http_proxy и HTTP_PROXY — формально две разные переменные. Разные программы читают разные варианты.

Исторически сложилось так:

• Утилита curl читает и строчный, и прописной варианты, но у строчного http_proxy есть особенность безопасности — прописной HTTP_PROXY curl игнорирует в CGI-окружении, чтобы избежать атак.
• Утилита wget традиционно предпочитает строчные имена.
• Многие программы на разных языках читают прописные варианты.

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

Формат NO_PROXY и почему он не понимает CIDR

Переменная NO_PROXY содержит список адресов через запятую, к которым нужно обращаться напрямую. Это критично для внутренних ресурсов: базы данных, локальные сервисы, метаданные облака.

Пример корректного значения:

localhost,127.0.0.1,.example.com,.internal,169.254.169.254

Обратите внимание на точку перед example.com. Точка означает, что под правило попадают все поддомены: api.example.com, git.example.com и так далее.

⚠️ Внимание: NO_PROXY, как правило, не понимает CIDR-нотацию и маски подсетей. Запись вида 10.0.0.0/8 в большинстве инструментов работать не будет. Некоторые современные версии библиотек это поддерживают, но полагаться на это нельзя. Перечисляйте конкретные адреса и доменные суффиксы явно.

Также NO_PROXY обычно не поддерживает звёздочки как универсальный шаблон. Не пишите *.example.com — используйте точку в начале: .example.com.

Совет: всегда добавляйте в NO_PROXY адрес localhost и 127.0.0.1. Иначе локальные запросы пойдут через прокси и, скорее всего, сломаются.

✅ Проверка: вы понимаете, зачем нужны HTTP_PROXY, HTTPS_PROXY и NO_PROXY, знаете про разницу регистра и помните, что NO_PROXY не любит CIDR. Теперь можно переходить к практике.

Шаг 1: включаем прокси в текущей сессии и проверяем curl

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

Задаём переменные через export

Команда export создаёт переменную окружения в текущей сессии. Выполните следующие команды, подставив свой URL прокси.

1. Откройте терминал.
2. Введите команду для HTTP: export http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Введите команду для HTTPS: export https_proxy="http://ivan:secret123@proxy.example.com:3128"
4. Продублируйте в прописном регистре: export HTTP_PROXY="$http_proxy"
5. И ещё раз: export HTTPS_PROXY="$https_proxy"
6. Задайте исключения: export no_proxy="localhost,127.0.0.1,.example.com"
7. Продублируйте: export NO_PROXY="$no_proxy"

Конструкция "$http_proxy" подставляет значение уже заданной строчной переменной, чтобы не печатать URL заново.

Совет: заметьте, что весь URL заключён в двойные кавычки. Это защищает от неправильной интерпретации спецсимволов вашей оболочкой bash.

Проверяем через curl

Теперь проверим, что переменные читаются. Утилита curl отлично для этого подходит.

1. Проверьте, что переменная задана: echo $http_proxy — вы должны увидеть свой URL.
2. Выполните запрос с подробным выводом: curl -v http://example.com
3. В выводе ищите строку, где упоминается Connected to proxy.example.com — это значит, что curl пошёл через прокси.

Если авторизация верна и прокси доступен, вы получите HTML-страницу в ответе. Если видите ошибку 407, значит проблема с логином или паролем — вернитесь к разделу про кодирование пароля.

Совет: флаг -v (verbose) показывает подробности соединения. Это ваш главный инструмент отладки прокси. Без него вы не увидите, куда именно идёт запрос.

Чтобы отключить прокси в текущей сессии, используйте команду unset: unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY. Все переменные исчезнут.

✅ Проверка: команда curl -v http://example.com показывает подключение через ваш прокси-сервер и возвращает содержимое страницы. Если да — первый шаг пройден успешно.

Шаг 2: делаем настройку постоянной

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

Вариант A: только для вашего пользователя через ~/.bashrc

Файл ~/.bashrc выполняется каждый раз при открытии интерактивного терминала под вашим пользователем. Это самый безопасный вариант — вы не трогаете других пользователей системы.

1. Откройте файл редактором: nano ~/.bashrc
2. Пролистайте в самый конец файла.
3. Добавьте те же строки export, что и в Шаге 1.
4. Сохраните файл: нажмите Ctrl+O, затем Enter, потом Ctrl+X для выхода.
5. Примените изменения без перезагрузки: source ~/.bashrc

Совет: перед редактированием сделайте резервную копию командой cp ~/.bashrc ~/.bashrc.backup. Если что-то пойдёт не так, вы легко восстановите оригинал.

Вариант B: для всей системы через /etc/environment

Файл /etc/environment задаёт переменные для всех пользователей и работает даже вне bash. Формат здесь особый: без слова export, просто ИМЯ=значение.

1. Откройте файл с правами администратора: sudo nano /etc/environment
2. Добавьте строки без export, например: http_proxy="http://ivan:secret123@proxy.example.com:3128"
3. Добавьте аналогично https_proxy, HTTP_PROXY, HTTPS_PROXY, no_proxy, NO_PROXY.
4. Сохраните и выйдите.
5. Чтобы применить, выйдите из системы и войдите заново, либо перезагрузитесь.

Вариант C: через /etc/profile.d

Более гибкий системный способ — создать отдельный скрипт в папке /etc/profile.d. Все .sh-файлы оттуда выполняются при входе.

1. Создайте файл: sudo nano /etc/profile.d/proxy.sh
2. Внутри используйте обычные команды export, как в Шаге 1.
3. Сохраните файл.
4. Сделайте его исполняемым: sudo chmod +x /etc/profile.d/proxy.sh

Этот способ удобнее /etc/environment, потому что поддерживает полноценный синтаксис оболочки.

Вариант D: для системных сервисов через systemd drop-in

Внимание, это важный нюанс. Фоновые службы, которыми управляет systemd, не читают ваш ~/.bashrc и часто игнорируют /etc/environment. Для них нужен отдельный подход — drop-in файл.

Допустим, вам нужно, чтобы через прокси работала конкретная служба, например some-service.

1. Создайте drop-in каталог и файл командой: sudo systemctl edit some-service
2. Откроется редактор. Впишите блок настроек.
3. В секции [Service] добавьте строки вида Environment="HTTP_PROXY=http://ivan:secret123@proxy.example.com:3128"
4. Добавьте аналогичные строки Environment для HTTPS_PROXY и NO_PROXY.
5. Сохраните файл.
6. Перечитайте конфигурацию: sudo systemctl daemon-reload
7. Перезапустите службу: sudo systemctl restart some-service

Директива Environment задаёт переменную именно для этой службы. Это единственно верный способ для systemd-сервисов.

⚠️ Внимание: на RHEL, CentOS, Fedora и AlmaLinux пути и инструменты те же самые — systemd работает одинаково. Отличия появятся позже, в разделе про пакетные менеджеры.

✅ Проверка: откройте новый терминал (не тот, где делали export вручную) и выполните echo $http_proxy. Если видите свой URL — постоянная настройка работает.

Шаг 3: настраиваем пакетные менеджеры и утилиты по отдельности

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

apt на Ubuntu и Debian

Менеджер пакетов apt часто запускается через sudo и может не видеть ваши переменные. Надёжнее задать прокси в его собственном конфиге.

1. Создайте файл: sudo nano /etc/apt/apt.conf.d/95proxies
2. Добавьте строку: Acquire::http::Proxy "http://ivan:secret123@proxy.example.com:3128";
3. Добавьте строку для HTTPS: Acquire::https::Proxy "http://ivan:secret123@proxy.example.com:3128";
4. Сохраните файл.
5. Проверьте: sudo apt update

Обратите внимание на точку с запятой в конце каждой строки — это обязательный элемент синтаксиса apt.

dnf и yum на RHEL, Fedora, AlmaLinux

На системах семейства RHEL вместо apt используются dnf и yum. Прокси задаётся в главном конфиге.

1. Откройте файл: sudo nano /etc/dnf/dnf.conf (для старых систем /etc/yum.conf)
2. В секцию [main] добавьте строку: proxy=http://proxy.example.com:3128
3. Если нужна авторизация, добавьте отдельно: proxy_username=ivan и proxy_password=secret123
4. Сохраните файл.
5. Проверьте: sudo dnf makecache

В dnf логин и пароль удобнее задавать отдельными директивами, а не внутри URL.

npm через .npmrc

1. Задайте прокси командой: npm config set proxy "http://ivan:secret123@proxy.example.com:3128"
2. Задайте для HTTPS: npm config set https-proxy "http://ivan:secret123@proxy.example.com:3128"
3. Настройки запишутся в файл ~/.npmrc автоматически.
4. Проверьте: npm config get proxy

pip через pip.conf

1. Создайте каталог: mkdir -p ~/.config/pip
2. Откройте файл: nano ~/.config/pip/pip.conf
3. Добавьте секцию [global] и строку proxy = http://ivan:secret123@proxy.example.com:3128
4. Сохраните файл.
5. Проверьте установкой любого пакета: pip install requests

Альтернативно можно указать прокси прямо в команде: pip install requests --proxy http://proxy.example.com:3128

git через http.proxy

1. Задайте глобально: git config --global http.proxy "http://ivan:secret123@proxy.example.com:3128"
2. При необходимости отдельно для HTTPS: git config --global https.proxy "http://ivan:secret123@proxy.example.com:3128"
3. Проверьте: git config --global --get http.proxy

Чтобы удалить настройку: git config --global --unset http.proxy

git по SSH через ProxyCommand

Если вы клонируете репозитории по SSH (адрес вида git@github.com), настройка http.proxy не поможет — SSH это другой протокол. Здесь нужен ProxyCommand.

1. Откройте файл: nano ~/.ssh/config
2. Добавьте блок для нужного хоста: строка Host github.com, затем с отступом строка ProxyCommand nc -X connect -x proxy.example.com:3128 %h %p
3. Сохраните файл.
4. Установите утилиту netcat, если её нет: sudo apt install netcat-openbsd на Ubuntu, sudo dnf install nmap-ncat на RHEL.

Здесь %h и %p автоматически заменяются на хост и порт назначения. Флаг -X connect указывает netcat использовать HTTP-прокси.

curl через .curlrc

1. Откройте файл: nano ~/.curlrc
2. Добавьте строку: proxy = "http://ivan:secret123@proxy.example.com:3128"
3. Сохраните файл.

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

wget через .wgetrc

1. Откройте файл: nano ~/.wgetrc
2. Добавьте строки: http_proxy = http://proxy.example.com:3128 и https_proxy = http://proxy.example.com:3128
3. Добавьте use_proxy = on
4. Сохраните файл.

composer для PHP

Composer читает переменную окружения HTTP_PROXY, так что часто отдельная настройка не нужна. Если хотите задать явно, используйте переменную в момент запуска: HTTP_PROXY=http://proxy.example.com:3128 composer install

Go и GOPROXY: важное предупреждение

⚠️ Внимание: переменная GOPROXY — это НЕ прокси-сервер в нашем смысле. Путать их нельзя. GOPROXY указывает на зеркало модулей Go — сервис, откуда скачиваются библиотеки. Это адрес репозитория, а не сетевой прокси.

Чтобы Go ходил в интернет через ваш обычный прокси, используйте стандартные HTTP_PROXY и HTTPS_PROXY. А GOPROXY оставьте в значении по умолчанию, если нет отдельной задачи менять зеркало модулей.

Совет: запомните правило — если в имени переменной есть слово PROXY, это ещё не значит, что она про ваш сетевой прокси. GOPROXY, npm registry и подобные — про источники пакетов.

✅ Проверка: выполните тестовую операцию каждым настроенным инструментом: sudo apt update, npm install, git ls-remote и так далее. Все должны успешно достучаться до сети.

Шаг 4: настраиваем Docker и Kubernetes

Цель этапа: Docker — особый случай. У него три разных места настройки прокси, и путать их — типичная ошибка. Разберём каждое.

Место 1: демон Docker через systemd drop-in

Эта настройка нужна, чтобы сам Docker мог скачивать образы из реестра. Демон Docker управляется systemd, поэтому используем уже знакомый механизм drop-in.

1. Создайте каталог: sudo mkdir -p /etc/systemd/system/docker.service.d
2. Создайте файл: sudo nano /etc/systemd/system/docker.service.d/proxy.conf
3. Добавьте секцию [Service].
4. Добавьте строку Environment="HTTP_PROXY=http://proxy.example.com:3128"
5. Добавьте аналогичные строки для HTTPS_PROXY и NO_PROXY.
6. Перечитайте конфигурацию: sudo systemctl daemon-reload
7. Перезапустите Docker: sudo systemctl restart docker

Проверить можно командой: sudo systemctl show --property=Environment docker

Место 2: сборка образа через build-arg

При сборке образа команды внутри Dockerfile (например, apt install) выполняются в изолированном окружении, которое не видит прокси хоста. Прокси нужно передать явно.

1. В Dockerfile добавьте инструкции ARG http_proxy и ARG https_proxy до команд RUN.
2. Соберите образ с передачей аргументов: docker build --build-arg http_proxy=http://proxy.example.com:3128 --build-arg https_proxy=http://proxy.example.com:3128 -t myimage .

⚠️ Внимание: не вписывайте пароль от прокси прямо в Dockerfile инструкцией ENV. Он останется в слоях образа, и любой, кто получит образ, увидит пароль. Используйте именно build-arg, а лучше прокси без пароля для сборки.

Место 3: контейнеры при запуске через ~/.docker/config.json

Чтобы запущенные контейнеры автоматически получали переменные прокси, настройте клиентский конфиг Docker.

1. Откройте файл: nano ~/.docker/config.json
2. Добавьте блок proxies с секцией default.
3. Внутри укажите httpProxy, httpsProxy и noProxy со своими значениями.
4. Сохраните файл.

Теперь при каждом docker run переменные автоматически прокинутся внутрь контейнера.

Переменные в манифесте Kubernetes

В Kubernetes прокси задаётся через переменные окружения в спецификации контейнера. В разделе env манифеста Pod или Deployment добавьте элементы с name HTTP_PROXY, HTTPS_PROXY, NO_PROXY и соответствующими value.

Совет: секретные значения в Kubernetes храните в объекте Secret и подключайте через valueFrom, а не пишите пароль прямо в манифест. Так пароль не окажется в системе контроля версий.

✅ Проверка: выполните docker pull hello-world — образ должен скачаться. Затем docker run --rm alpine env | grep -i proxy — увидите проброшенные переменные внутри контейнера.

Шаг 5: настраиваем прокси в CI — GitHub Actions и GitLab Runner

Цель этапа: заставить пайплайны CI работать через прокси, при этом безопасно храня доступ и не светя пароль в логах.

Хранение доступа в секретах

Главное правило CI: никогда не пишите пароль прокси прямо в YAML-файле пайплайна. Файл лежит в репозитории, и пароль увидят все. Используйте механизм секретов.

В GitHub Actions секреты добавляются в настройках репозитория, раздел Settings, затем Secrets and variables, затем Actions. Создайте секрет с именем PROXY_URL и вставьте туда полный URL прокси.

В GitLab секреты называются CI/CD variables. Они добавляются в Settings, затем CI/CD, затем Variables. Обязательно включите галочки Masked и Protected для чувствительных значений.

Настройка GitHub Actions

1. В файле пайплайна .github/workflows добавьте на уровне job блок env.
2. Задайте HTTP_PROXY со значением из секрета через синтаксис двойных фигурных скобок с secrets.PROXY_URL.
3. Аналогично задайте HTTPS_PROXY и NO_PROXY.
4. Эти переменные будут доступны всем шагам job.

Настройка GitLab Runner

В GitLab есть два уровня. Можно задать переменные в самом файле .gitlab-ci.yml через блок variables, а можно на уровне раннера в его конфиге config.toml через секцию environment.

1. Для проекта: добавьте в .gitlab-ci.yml блок variables со ссылками на защищённые переменные.
2. Для всех проектов раннера: откройте config.toml раннера и в секции [[runners]] добавьте параметр environment со списком нужных переменных.

Маскирование пароля в логах

Даже с секретами пароль может случайно попасть в лог, если какая-то команда его выведет. GitHub Actions автоматически маскирует значения секретов звёздочками. В GitLab за это отвечает галочка Masked — но она работает только если значение соответствует требованиям (без некоторых спецсимволов и достаточной длины).

⚠️ Внимание: избегайте команд с флагом -v или echo, которые печатают полный URL прокси в лог. Даже с маскированием лучше не рисковать. Для отладки печатайте только адрес и порт без логина и пароля.

Совет: храните URL прокси без встроенного пароля, а логин и пароль — отдельными секретами. Так их проще маскировать и ротировать.

✅ Проверка: запустите пайплайн вручную. Шаг, который выполняет сетевой запрос (например установку зависимостей), должен успешно завершиться. В логах пароль виден быть не должен.

Проверка результата: убеждаемся, что трафик реально идёт через прокси

Настроить мало — нужно доказать, что трафик действительно проходит через прокси, а не идёт напрямую. Вот чек-лист проверок.

Чек-лист что должно работать

• Команда echo $http_proxy в новом терминале показывает ваш URL.
• curl -v http://example.com показывает строку Connected to прокси.
• sudo apt update успешно обновляет списки пакетов.
• git ls-remote до удалённого репозитория проходит.
• docker pull скачивает образ.
• Пайплайн CI завершается зелёным.

Как протестировать надёжно

Самый честный способ — узнать, какой внешний IP-адрес видит сервер назначения. Выполните запрос к сервису, показывающему ваш IP. Если через прокси, вы увидите IP-адрес прокси-сервера, а не свой собственный.

1. Выполните запрос без прокси: env -u http_proxy -u https_proxy curl -s http://ifconfig.me — увидите свой реальный IP.
2. Выполните с прокси: curl -s http://ifconfig.me — увидите IP прокси.
3. Если два адреса различаются — прокси работает.

Ещё один способ — посмотреть логи самого прокси-сервера, если у вас есть к ним доступ. Ваши запросы должны там появляться.

Совет: команда env -u временно убирает переменную только для одной команды, не трогая сессию. Удобно для сравнения поведения с прокси и без.

✅ Проверка: IP-адрес с прокси отличается от прямого. Это стопроцентное доказательство, что трафик идёт через прокси.

Типичные ошибки и их решения

Разберём частые проблемы. Формат простой: проблема, причина, решение.

Проблема 1: sudo не наследует переменные

Причина: sudo по умолчанию очищает окружение из соображений безопасности. Ваши export не доходят до команды под sudo.

Решение: используйте флаг -E, чтобы сохранить окружение: sudo -E apt update. Либо настройте постоянное сохранение через файл sudoers. Выполните sudo visudo и добавьте строку Defaults env_keep += "http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY". После этого sudo будет пропускать эти переменные всегда.

Проблема 2: ошибки сертификатов

Причина: некоторые корпоративные прокси перехватывают HTTPS и подменяют сертификаты своим корневым сертификатом. Система его не знает и ругается на недоверенное соединение.

Решение: получите у администратора корневой сертификат прокси. На Ubuntu и Debian скопируйте его в /usr/local/share/ca-certificates с расширением .crt и выполните sudo update-ca-certificates. На RHEL положите в /etc/pki/ca-trust/source/anchors и выполните sudo update-ca-trust. После этого все инструменты начнут доверять прокси.

Проблема 3: curl работает, apt не работает

Причина: curl читает переменные окружения, а apt под sudo их не видит и не имеет своего конфига прокси.

Решение: настройте прокси в /etc/apt/apt.conf.d, как описано в Шаге 3. Это отдельная от переменных окружения настройка, и именно она нужна apt.

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

Причина: символы @, :, / в незакодированном пароле ломают разбор URL.

Решение: примените percent-encoding из раздела Подготовки. Замените @ на %40, : на %3A и так далее.

Проблема 5: ошибка 407 Proxy Authentication Required

Причина: неверный логин или пароль, либо прокси требует авторизацию, а вы её не указали.

Решение: перепроверьте логин и пароль. Убедитесь, что данные авторизации есть в URL. Проверьте кодирование спецсимволов.

Проблема 6: внутренние ресурсы недоступны

Причина: запросы к локальным и внутренним адресам идут через прокси, который их не знает.

Решение: добавьте эти адреса в NO_PROXY. Не забудьте localhost, 127.0.0.1 и внутренние домены с точкой в начале.

Проблема 7: Docker-демон не видит прокси

Причина: вы настроили переменные в bashrc, но демон Docker управляется systemd и их не читает.

Решение: используйте systemd drop-in из Шага 4, не забудьте daemon-reload и restart docker.

Проблема 8: настройки не применились

Причина: вы отредактировали bashrc, но не перезапустили терминал.

Решение: выполните source ~/.bashrc или откройте новое окно терминала.

Дополнительные возможности и продвинутые настройки

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

Функции-переключатели прокси

Удобно завести в ~/.bashrc две функции: proxy_on для включения и proxy_off для выключения. Внутри proxy_on расположите команды export, внутри proxy_off — команды unset. Тогда переключение станет одной командой.

Разные прокси для разных задач

Вы можете задать прокси только для одной команды, не меняя окружение целиком. Пример: https_proxy=http://other:3128 curl https://example.com. Переменная действует только для этой команды.

SOCKS-прокси

Если у вас прокси типа SOCKS5, используйте схему socks5 в URL и переменную ALL_PROXY. Для curl есть флаг --socks5. Учтите, что не все утилиты умеют работать с SOCKS.

Совет: для инструментов, которые совсем не умеют в прокси, существуют обёртки вроде proxychains. Но применяйте их осознанно, они меняют поведение сетевых вызовов программы.

Сводная таблица настроек

Держите эту сводку под рукой. Формат: инструмент — файл конфигурации — переменная или директива.

• Сессия shell — временно в памяти — export http_proxy и HTTP_PROXY.
• Пользователь — ~/.bashrc — export переменных.
• Вся система — /etc/environment — http_proxy без export.
• Вся система — /etc/profile.d/proxy.sh — export переменных.
• systemd-сервис — drop-in через systemctl edit — директива Environment.
• apt (Ubuntu, Debian) — /etc/apt/apt.conf.d/95proxies — Acquire::http::Proxy.
• dnf, yum (RHEL) — /etc/dnf/dnf.conf — proxy, proxy_username, proxy_password.
• npm — ~/.npmrc — proxy и https-proxy.
• pip — ~/.config/pip/pip.conf — proxy в секции global.
• git по HTTPS — глобальный конфиг git — http.proxy.
• git по SSH — ~/.ssh/config — ProxyCommand.
• curl — ~/.curlrc — proxy.
• wget — ~/.wgetrc — http_proxy, https_proxy, use_proxy.
• composer — окружение — HTTP_PROXY.
• Docker демон — /etc/systemd/system/docker.service.d/proxy.conf — Environment.
• Docker сборка — команда build — build-arg http_proxy.
• Docker контейнеры — ~/.docker/config.json — блок proxies.
• Kubernetes — манифест Pod — env с HTTP_PROXY.
• GitHub Actions — файл workflow — блок env с secrets.
• GitLab — .gitlab-ci.yml или config.toml — variables или environment.

FAQ: частые вопросы по настройке прокси

Нужно ли задавать и строчные, и прописные переменные?

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

Почему curl видит прокси, а apt нет?

Потому что apt под sudo не наследует переменные окружения и имеет собственный конфиг. Настройте apt отдельно через файл в /etc/apt/apt.conf.d.

Как временно отключить прокси для одной команды?

Используйте env -u http_proxy -u https_proxy перед командой. Это уберёт переменные только для этого запуска.

Можно ли указать подсеть в NO_PROXY?

Как правило, нет. NO_PROXY не понимает CIDR-нотацию надёжно. Перечисляйте конкретные адреса и доменные суффиксы с точкой в начале.

GOPROXY — это мой прокси-сервер?

Нет. GOPROXY указывает на зеркало модулей Go, а не на сетевой прокси. Для сетевого прокси в Go используйте HTTP_PROXY и HTTPS_PROXY.

Как безопасно хранить пароль прокси?

В CI используйте секреты. Локально применяйте файл .netrc с правами 600 или менеджер паролей. Избегайте пароля в истории команд.

Почему git по SSH не идёт через http.proxy?

Потому что SSH — отдельный протокол. Настройте ProxyCommand в файле ~/.ssh/config для нужного хоста.

Что делать при ошибках сертификата через прокси?

Установите корневой сертификат прокси в системное хранилище и обновите доверие командой update-ca-certificates на Debian или update-ca-trust на RHEL.

Настройки в bashrc не работают в новом сеансе, почему?

Возможно, вы редактировали не тот файл, либо не сохранили изменения, либо не открыли новый терминал. Проверьте через echo и source.

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

Сравните внешний IP с прокси и без него командой curl к сервису определения IP. Разные адреса подтверждают работу прокси.

Заключение: что вы освоили и куда двигаться дальше

Поздравляем, вы прошли большой путь. Давайте резюмируем, что теперь умеете.

Вы научились собирать корректный URL прокси и кодировать спецсимволы в пароле. Разобрались с переменными HTTP_PROXY, HTTPS_PROXY и NO_PROXY, включая тонкости регистра и формата исключений. Вы умеете включать прокси в сессии и делать настройку постоянной несколькими способами, включая systemd drop-in для служб.

Вы настроили прокси для всех ключевых инструментов: apt и dnf, npm и pip, git по HTTPS и по SSH, curl и wget, composer, а также поняли важное отличие GOPROXY. Вы освоили три места настройки Docker и переменные в Kubernetes. Наконец, вы настроили прокси в GitHub Actions и GitLab с безопасным хранением секретов и маскированием пароля.

Что делать дальше: закрепите знания практикой. Настройте прокси на тестовой машине с нуля, следуя гайду. Заведите функции-переключатели для удобства. Изучите логи вашего прокси-сервера, чтобы видеть трафик своими глазами.

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

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

Вы отлично справились. Теперь прокси в терминале Linux и в CI не представляет для вас никакой загадки. Удачных настроек и стабильных соединений.