docker pull por VPN: o daemon ten a súa propia rede

O teu portátil está na VPN corporativa, curl chega ao rexistro interno e, aínda así, docker pull falla cun EOF. Esa combinación non é unha contradición. A orde que escribiches execútase na túa shell, pero a transferencia execútase no daemon que escollese a CLI de Docker, e ese daemon pode estar nun host completamente distinto. A súa ruta de rede é a que ten que funcionar, e a súa configuración de proxy é a que se aplica.

Comeza identificando o motor, non a ruta

Executa docker context show e docker version. A saída da versión imprime unha sección de cliente e unha sección de servidor, e o bloque do servidor diche quen respondeu: un motor nativo local, a máquina virtual de Docker Desktop ou un daemon nunha máquina remota. docker context inspect amosará o punto final do contexto seleccionado se queres estar seguro, e ningún destes comandos cambia nada.

Unha variable de contorno como DOCKER_HOST pode apuntar en silencio a CLI a un motor distinto do que supoñas, que é a explicación habitual dun portátil que parece estar na VPN mentres a descarga viaxa a outro sitio.

O daemon ten a súa propia identidade de rede

Un motor remoto necesita a súa propia ruta aprobada cara ao rexistro privado. Conectar o cliente VPN do teu portátil dálle unha ruta a ese portátil; non lle dá a mesma dirección privada a un daemon que está nun laboratorio ou nunha subrede da nube. Se o motor é Docker Desktop, a descarga ocorre dentro da súa máquina virtual, que ten a súa propia configuración de rede e de proxy, separada do contorno da túa shell.

Por iso un curl correcto no host é unha proba sobre o host e nada máis.

Averigua que intercambio co rexistro rematou

A descarga dunha imaxe é unha secuencia: autenticación, obtención do manifesto e despois transferencias de blob que a miúdo se redirixen a almacenamento de obxectos ou a un punto final de CDN. Un docker login correcto só demostra o primeiro paso, e un token pode ser perfectamente válido mentres o host de blob redirixido non é alcanzable desde a rede do daemon. Anota a hora exacta, a referencia da imaxe e o primeiro evento útil do rexistro do daemon ou do cliente antes de cambiar nada.

EOF por si só non nomea ningunha causa. Pode ser unha conexión truncada, un proxy que soltou o fluxo, un tempo de espera esgotado ou un problema de MTU, e adiviñar entre eles sen o evento con marca de tempo é como a xente acaba reconstruíndo un motor san. Trata o desprazamento de bytes da saída do cliente como dato, porque unha transferencia que se detén sempre no mesmo tamaño é un animal distinto dunha que nunca comeza. Rexistra ambos os resultados e compáraos entre intentos.

Configura o compoñente que transfire

Para un motor Linux nativo, o proxy vai no contorno do servizo, non na túa shell. Un ficheiro drop-in en /etc/systemd/system/docker.service.d/ con entradas HTTP_PROXY, HTTPS_PROXY e NO_PROXY, seguido de systemctl daemon-reload e un reinicio, é a disposición documentada. Docker Desktop expón os mesmos valores mediante a súa propia configuración, e editar un perfil de shell non toca ningún dos dous.

Se se debe chegar ao rexistro directamente pola VPN, o daemon necesita un resolutor, unha ruta e unha exclusión de proxy deliberada, non só unha exclusión. A coincidencia de NO_PROXY é unha comparación de cadeas por compoñente, e unha exención sen ruta subxacente produce un fallo que parece un problema de proxy.

Cando a inspección TLS corporativa está na ruta aprobada, instala a súa raíz verificada mediante o fluxo do motor ou de Desktop. Engadir o rexistro a insecure-registries é un cambio distinto que desactiva a validación, e non é unha configuración de almacén de confianza.

Repite unha descarga controlada e comproba que cambiou

Cambia unha fronteira, reinicia o compoñente que a posúe e repite a mesma descarga desde o mesmo contexto. Verifica a referencia de imaxe e o digest resultantes, non a ausencia de erro, porque unha capa na caché pode facer que o segundo intento percorra moita menos parte da ruta que o primeiro. Garda no ticket as transferencias que realmente ocorreron, xa que son o único rexistro do que o reintento probou de verdade.

Os pasos de compilación e os contedores en execución teñen os seus propios contextos de rede, así que trátaos como preguntas separadas cando a propia descarga xa funcione.