Docker build через прокси в 2026: практическая настройка с личным VPS

Чтобы docker build работал через прокси, нужно настроить прокси для Docker CLI и, если требуется, для демона Docker. В 2026 году основной способ — файл ~/.docker/config.json для CLI и daemon.json или systemd для демона. С личным VPS SANSARA вы получаете выделенный узел в одной из 9+ стран, подключаетесь через защищённый канал и используете его как шлюз для Docker.

Коротко:

• Docker CLI использует ~/.docker/config.json для автоматической передачи прокси в контейнеры и сборки.
• Docker daemon настраивается через systemd (/etc/systemd/system/docker.service.d/http-proxy.conf) или daemon.json.
• Переменные HTTP_PROXY, HTTPS_PROXY и NO_PROXY должны быть согласованы между CLI и демоном.
• Личный VPS SANSARA выступает как выделенный узел-шлюз, через который Docker получает доступ к реестрам и внешним ресурсам.

Что это и кому подходит

Настройка прокси для docker build нужна, когда сборка образа требует доступа к внешним ресурсам (Docker Hub, сторонние репозитории, apt-репозитории), но сеть ограничена корпоративным файрволом или политиками безопасности. Вместо прямого выхода в интернет Docker направляет трафик через прокси-сервер.

Кому это полезно:

• Разработчикам в корпоративных сетях с обязательным прокси.
• Администраторам, которые хотят контролировать и логировать внешние запросы Docker.
• Пользователям, которые используют личный VPS как шлюз для всех внешних подключений.

В SANSARA вы получаете личный VPS с готовым подключением: регистрация → данные в кабинете → импорт в клиент на устройстве. Это даёт вам выделенный узел вместо общего пула, что удобно для стабильного прокси-шлюза под Docker.

Как настроить по шагам (с личным VPS SANSARA)

Предположим, у вас уже есть личный VPS SANSARA с работающим прокси-сервером (например, на порту 3128). Ниже — практические шаги для Linux-сервера, где вы запускаете Docker.

1. Настройка прокси для Docker CLI (docker build)

Создайте или отредактируйте файл ~/.docker/config.json:

`json { "proxies": { "default": { "httpProxy": "http://your-sansara-vps-ip:3128", "httpsProxy": "http://your-sansara-vps-ip:3128", "noProxy": "localhost,127.0.0.1,.internal,*.local" } } } `

Здесь:

• httpProxy и httpsProxy — адрес вашего личного VPS SANSARA с портом прокси.
• noProxy — список хостов, которые не должны идти через прокси (локальные сервисы, внутренние реестры).

Эти настройки автоматически передаются как переменные окружения в контейнеры и в процесс сборки при docker build<source-chip title="Docker Docs" url="https://docs.docker.com/engine/cli/proxy" />.

После изменения файла перезапускать демон не нужно — изменения применяются к новым командам CLI.

2. Настройка Docker daemon (если нужен прокси для самого демона)

Если демон Docker (dockerd) тоже должен ходить через прокси (например, для docker pull из-под демона), есть два основных способа в 2026 году.

Через systemd (рекомендуется для систем на systemd):

Создайте файл /etc/systemd/system/docker.service.d/http-proxy.conf:

`ini [Service] Environment="HTTP_PROXY=http://your-sansara-vps-ip:3128" Environment="HTTPS_PROXY=http://your-sansara-vps-ip:3128" Environment="NO_PROXY=localhost,127.0.0.1,.internal,registry.internal" `

Затем:

`bash sudo systemctl daemon-reload sudo systemctl restart docker `

Через daemon.json (альтернативный способ):

Отредактируйте /etc/docker/daemon.json:

`json { "proxies": { "http-proxy": "http://your-sansara-vps-ip:3128", "https-proxy": "http://your-sansara-vps-ip:3128", "no-proxy": "localhost,127.0.0.1,.internal,registry.internal" } } `

И перезапустите демон:

`bash sudo systemctl restart docker `

Эти настройки обеспечивают, что сам демон Docker использует прокси для внешних запросов<source-chip title="Akmatori Blog" url="https://akmatori.com/blog/docker-proxy-configuration" />.

3. Разовый прокси для конкретного docker build

Если вы не хотите менять глобальные настройки, можно передать прокси как build-аргументы:

`bash docker build \ --build-arg HTTP_PROXY=http://your-sansara-vps-ip:3128 \ --build-arg HTTPS_PROXY=http://your-sansara-vps-ip:3128 \ --build-arg NO_PROXY=localhost,127.0.0.1 \ -t myapp . `

В Dockerfile используйте ARG для этих переменных, если они нужны во время сборки:

`dockerfile ARG HTTP_PROXY ARG HTTPS_PROXY ARG NO_PROXY

FROM ubuntu:22.04

`

Такой подход удобен для CI/CD или одноразовых сборок.

4. Использование личного VPS SANSARA как шлюза

В SANSARA после регистрации вы получаете данные для подключения к личному VPS. Вы можете:

• Развернуть на нём прокси-сервер (например, Squid, TinyProxy) и использовать его IP как your-sansara-vps-ip.
• Выбрать локацию из 9+ стран, чтобы шлюз был географически ближе к нужным реестрам.
• Настроить защищённый канал между вашей рабочей машиной и VPS, если требуется шифрование.

Telegram-бот SANSARA помогает быстро получить данные подключения и управлять услугами без входа в веб-кабинет.

Устройства: iPhone, Android, Windows, macOS

Хотя docker build обычно выполняется на сервере или рабочей станции, настройка прокси через личный VPS SANSARA касается в первую очередь устройства, где запущен Docker.

• Windows / macOS (Docker Desktop):

Docker Desktop использует те же файлы конфигурации (~/.docker/config.json на macOS/Linux, %USERPROFILE%\.docker\config.json на Windows). Настройка прокси для CLI и демона выполняется аналогично Linux.

• Linux-сервер или виртуальная машина:

Шаги выше подходят для любого дистрибутива с systemd и стандартной установкой Docker.

• iPhone / Android:

На мобильных устройствах docker build обычно не запускают напрямую. Но если вы управляете удалённым Docker-хостом с телефона (через SSH-клиент), то прокси настраивается на стороне сервера, а телефон лишь предоставляет доступ к терминалу. SANSARA поддерживает клиенты для iOS и Android, чтобы подключиться к личному VPS и далее работать с Docker через SSH.

Таким образом, неважно, с какого устройства вы подключаетесь к Docker-хосту — прокси настраивается на самом хосте, а VPS SANSARA служит шлюзом для этого хоста.

Частые ошибки и как их избежать

1. 01NO_PROXY не настроен или настроен неправильно

Если NO_PROXY пуст или не включает локальные адреса, локальные запросы (например, к внутреннему registry) могут пытаться идти через прокси и падать. Всегда добавляйте localhost, 127.0.0.1 и внутренние домены в noProxy<source-chip title="Akmatori Blog" url="https://akmatori.com/blog/docker-proxy-configuration" />.

1. 01Несоответствие настроек CLI и демона

Если демон настроен на один прокси, а CLI — на другой (или не настроен), часть запросов может идти напрямую, а часть — через прокси. Проверяйте обе конфигурации.

1. 01Прокси требует аутентификации, но она не указана

Если прокси на VPS требует логин и пароль, укажите их в URL: http://user:pass@your-sansara-vps-ip:3128. Убедитесь, что пароль не попадает в логи и публичные репозитории.

1. 01Старый способ с ENV в Dockerfile

Раньше часто прописывали ENV HTTP_PROXY ... прямо в Dockerfile. Это небезопасно и привязывает образ к инфраструктуре. Лучше использовать --build-arg или ~/.docker/config.json<source-chip title="Docker Docs" url="https://docs.docker.com/engine/cli/proxy" />.

1. 01Прокси недоступен с Docker-хоста

Убедитесь, что с хоста, где работает Docker, есть сетевой доступ к вашему VPS SANSARA на нужном порту. Проверьте telnet your-sansara-vps-ip 3128 или curl -x http://your-sansara-vps-ip:3128 http://ifconfig.me.

FAQ

• Корректность IP и порта VPS.
• Наличие noProxy и его синтаксис.
• Что демон перезапущен после изменений.
• Логи демона: journalctl -u docker -n 50.

Итог

• Настройте ~/.docker/config.json с прокси на ваш личный VPS SANSARA — это основной способ для docker build в 2026.
• При необходимости настройте демон через systemd или daemon.json, согласовав NO_PROXY с локальными адресами.
• Используйте --build-arg для разовых сборок вместо жёсткого ENV в Dockerfile.
• Выбирайте локацию VPS из 9+ стран SANSARA для лучшей географической близости к реестрам.
• Проверяйте доступность прокси и логи Docker при проблемах.

С личным VPS SANSARA вы получаете выделенный узел-шлюз, через который Docker безопасно обращается к внешним ресурсам, а импорт конфигурации из кабинета и поддержка всех основных ОС упрощают начальную настройку.