docker pull через VPN: у демона своя сеть

Ваш ноутбук находится в корпоративной сети VPN, curl доходит до внутреннего registry, и всё же docker pull по-прежнему падает с EOF. Это сочетание не противоречие. Введённая вами команда выполняется в вашей оболочке, но передача идёт в том демоне, который выбрал Docker CLI, и этот демон может находиться совсем на другом хосте. Работать должен именно его сетевой путь, и применяются именно его настройки прокси.

Начните с определения движка, а не маршрута

Выполните docker context show и docker version. Вывод версии печатает раздел клиента и раздел сервера, а блок сервера сообщает, что ответило: локальный нативный движок, виртуальная машина Docker Desktop или демон на удалённой машине. docker context inspect покажет конечную точку выбранного контекста, если вы хотите убедиться, и ни одна из этих команд ничего не меняет.

Переменная окружения вроде DOCKER_HOST может молча направить CLI к другому движку, не тому, который вы предполагаете, и это обычное объяснение ноутбука, который выглядит подключённым к VPN, пока загрузка уходит куда-то ещё.

У демона есть собственная сетевая идентичность

Удалённому движку нужен собственный одобренный путь к приватному registry. Подключение VPN-клиента на ноутбуке даёт маршрут этому ноутбуку; оно не даёт демону в лаборатории или облачной подсети тот же приватный адрес. Если движок — Docker Desktop, загрузка происходит внутри его виртуальной машины, у которой своя конфигурация сети и прокси, отдельная от окружения вашей оболочки.

Поэтому успешный curl на хосте — доказательство о хосте и не более того.

Выясните, какой обмен с registry завершился

Загрузка образа — это последовательность: аутентификация, получение манифеста, затем передача блобов, которая часто перенаправляется в объектное хранилище или на конечную точку CDN. Успешный docker login доказывает только первый шаг, и токен может быть полностью действительным, пока перенаправленный хост блобов недоступен из сети демона. Прежде чем что-либо менять, запишите точное время, ссылку на образ и первое полезное событие из журнала демона или клиента.

Сам по себе EOF не называет причину. Это может быть оборванное соединение, прокси, сбросивший поток, тайм-аут или проблема с MTU, и угадывание между ними без события с отметкой времени — это путь, которым люди начинают перестраивать здоровый движок. Относитесь к смещению в байтах в выводе клиента как к данным, потому что передача, которая каждый раз останавливается на одном и том же размере, — совсем другой зверь, чем та, что не начинается никогда. Запишите оба результата и сравните их между попытками.

Настройте компонент, который выполняет передачу

Для нативного движка Linux прокси относится к окружению службы, а не к вашей оболочке. Файл drop-in в /etc/systemd/system/docker.service.d/ с записями HTTP_PROXY, HTTPS_PROXY и NO_PROXY, за которым следуют systemctl daemon-reload и перезапуск, — это документированная схема. Docker Desktop предоставляет те же значения через свои настройки, и редактирование профиля оболочки не затрагивает ни то, ни другое.

Если до registry нужно доходить напрямую через VPN, демону нужны резолвер, маршрут и намеренное исключение прокси, а не только исключение. Сопоставление NO_PROXY — это сравнение строк для каждого компонента, и исключение без лежащего в основе маршрута даёт сбой, который выглядит как проблема с прокси.

Когда корпоративная проверка TLS находится на одобренном пути, установите её проверенный корень через рабочий процесс движка или Desktop. Добавление registry в insecure-registries — это другое изменение, которое отключает проверку, и это не конфигурация хранилища доверия.

Повторите одну контролируемую загрузку и проверьте, что изменилось

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

Шаги сборки и работающие контейнеры имеют собственные сетевые контексты, поэтому рассматривайте их как отдельные вопросы, когда сама загрузка заработает.