docker pull através de uma VPN: o daemon tem a sua própria rede

O seu portátil está na VPN corporativa, curl chega ao registry interno e, mesmo assim, docker pull falha com um EOF. Essa combinação não é uma contradição. O comando que escreveu é executado na sua shell, mas a transferência é executada no daemon que a CLI do Docker selecionou, e esse daemon pode estar num host completamente diferente. É o caminho de rede dele que tem de funcionar, e são as definições de proxy dele que se aplicam.

Comece por identificar o motor, não a rota

Execute docker context show e docker version. A saída da versão imprime uma secção de cliente e uma secção de servidor, e o bloco do servidor diz-lhe quem respondeu: um motor nativo local, a máquina virtual do Docker Desktop ou um daemon numa máquina remota. docker context inspect mostrará o ponto final do contexto selecionado se quiser ter a certeza, e nenhum destes comandos altera nada.

Uma variável de ambiente como DOCKER_HOST pode apontar silenciosamente a CLI para um motor diferente do que assume, e é a explicação habitual para um portátil que parece estar na VPN enquanto o pull viaja para outro lado.

O daemon tem a sua própria identidade de rede

Um motor remoto precisa do seu próprio caminho aprovado para o registry privado. Ligar o cliente VPN do portátil dá uma rota a esse portátil; não dá o mesmo endereço privado a um daemon que está num laboratório ou numa sub-rede de nuvem. Se o motor for o Docker Desktop, o pull acontece dentro da máquina virtual dele, que tem a sua própria configuração de rede e de proxy, separada do ambiente da sua shell.

Por isso um curl bem-sucedido no host é uma prova sobre o host e nada mais.

Descubra qual troca com o registry terminou

O pull de uma imagem é uma sequência: autenticação, obtenção do manifesto e depois transferências de blob que muitas vezes são redirecionadas para armazenamento de objetos ou para um ponto final de CDN. Um docker login bem-sucedido prova apenas o primeiro passo, e um token pode estar perfeitamente válido enquanto o host de blob redirecionado não é alcançável a partir da rede do daemon. Registe a hora exata, a referência da imagem e o primeiro evento útil do registo do daemon ou do cliente antes de mudar seja o que for.

EOF sozinho não nomeia nenhuma causa. Pode ser uma ligação truncada, um proxy que largou o fluxo, um tempo limite esgotado ou um problema de MTU, e adivinhar entre eles sem o evento com data e hora é como as pessoas acabam a reconstruir um motor saudável. Trate o deslocamento de bytes na saída do cliente como dado, porque uma transferência que pára sempre no mesmo tamanho é um animal diferente de uma que nunca começa. Registre os dois resultados e compare-os entre tentativas.

Configure o componente que transfere

Para um motor Linux nativo, o proxy pertence ao ambiente do serviço, não à sua shell. Um ficheiro drop-in em /etc/systemd/system/docker.service.d/ com entradas HTTP_PROXY, HTTPS_PROXY e NO_PROXY, seguido de systemctl daemon-reload e de um reinício, é a disposição documentada. O Docker Desktop expõe os mesmos valores através das suas próprias definições, e editar um perfil de shell não toca em nenhum dos dois.

Se for preciso chegar ao registry diretamente pela VPN, o daemon precisa de um resolver, de uma rota e de uma exclusão de proxy deliberada, e não apenas de uma exclusão. A correspondência de NO_PROXY é uma comparação de cadeias por componente, e uma isenção sem rota subjacente produz uma falha que parece um problema de proxy.

Quando a inspeção TLS corporativa está no caminho aprovado, instale a raiz verificada através do fluxo de trabalho do motor ou do Desktop. Adicionar o registry a insecure-registries é uma alteração diferente que desativa a validação, e não é uma configuração de armazenamento de confiança.

Repita um pull controlado e verifique o que mudou

Altere uma fronteira, reinicie o componente que a possui e repita o mesmo pull a partir do mesmo contexto. Verifique a referência de imagem e o digest resultantes, não a ausência de erro, porque uma camada em cache pode fazer com que a segunda tentativa percorra muito menos do caminho do que a primeira. Guarde no ticket as transferências que realmente ocorreram, pois são o único registo do que a nova tentativa testou de facto.

Os passos de build e os contentores em execução têm os seus próprios contextos de rede, por isso trate-os como perguntas separadas quando o próprio pull já funcionar.