docker pull per VPN: el dimoni té la seva pròpia xarxa

El teu portàtil és a la VPN corporativa, curl arriba al registre intern i, tot i així, docker pull falla amb un EOF. Aquesta combinació no és cap contradicció. L'ordre que has escrit s'executa a la teva shell, però la transferència es fa al dimoni que hagi triat la CLI del Docker, i aquest dimoni pot ser en un altre host completament. El seu camí de xarxa és el que ha de funcionar, i la seva configuració de proxy és la que s'aplica.

Comença identificant el motor, no la ruta

Executa docker context show i docker version. La sortida de la versió imprimeix una secció de client i una secció de servidor, i el bloc del servidor et diu qui ha respost: un motor natiu local, la màquina virtual de Docker Desktop o un dimoni en una màquina remota. docker context inspect mostrarà el punt final del context seleccionat si vols assegurar-te'n, i cap d'aquestes ordres no canvia res.

Una variable d'entorn com DOCKER_HOST pot apuntar silenciosament la CLI a un motor diferent del que assumes, que és l'explicació habitual d'un portàtil que sembla estar a la VPN mentre l'extracció viatja a un altre lloc.

El dimoni té la seva pròpia identitat de xarxa

Un motor remot necessita el seu propi camí aprovat cap al registre privat. Connectar el client VPN del teu portàtil dona una ruta a aquest portàtil; no dona la mateixa adreça privada a un dimoni que és en un laboratori o en una subxarxa de núvol. Si el motor és Docker Desktop, l'extracció passa dins de la seva màquina virtual, que té la seva pròpia xarxa i configuració de proxy, separades de l'entorn de la teva shell.

Per això un curl correcte a l'amfitrió és una prova sobre l'amfitrió i res més.

Esbrina quin intercanvi amb el registre s'ha acabat

Una extracció d'imatge és una seqüència: autenticació, obtenció del manifest i després transferències de blob que sovint es redirigeixen a emmagatzematge d'objectes o a un punt final de CDN. Un docker login correcte només demostra el primer pas, i un testimoni pot ser perfectament vàlid mentre l'amfitrió de blob redirigit no és abastable des de la xarxa del dimoni. Anota l'hora exacta, la referència de la imatge i el primer esdeveniment útil del registre del dimoni o del client abans de canviar res.

EOF per si sol no indica cap causa. Pot ser una connexió truncada, un proxy que ha deixat caure el flux, un temps d'espera esgotat o un problema d'MTU, i endevinar entre aquestes opcions sense l'esdeveniment amb marca de temps és com la gent acaba reconstruint un motor sa. Tracta el desplaçament de bytes de la sortida del client com a dada, perquè una transferència que s'atura sempre a la mateixa mida és un animal diferent d'una que no comença mai. Registra tots dos resultats i compara'ls entre intents.

Configura el component que transfereix

Per a un motor Linux natiu, el proxy va a l'entorn del servei, no a la teva shell. Un fitxer drop-in sota /etc/systemd/system/docker.service.d/ amb entrades HTTP_PROXY, HTTPS_PROXY i NO_PROXY, seguit de systemctl daemon-reload i un reinici, és la disposició documentada. Docker Desktop exposa els mateixos valors mitjançant la seva pròpia configuració, i editar un perfil de shell no toca cap dels dos.

Si cal arribar al registre directament per la VPN, el dimoni necessita un resolutor, una ruta i una exclusió de proxy deliberada, no només una exclusió. La coincidència de NO_PROXY és una comparació de cadenes per component, i una exempció sense ruta subjacent produeix un error que sembla un problema de proxy.

Quan la inspecció TLS corporativa és al camí aprovat, instal·la la seva arrel verificada mitjançant el flux del motor o de Desktop. Afegir el registre a insecure-registries és un canvi diferent que desactiva la validació, i no és una configuració de magatzem de confiança.

Repeteix una extracció controlada i comprova què ha canviat

Canvia una frontera, reinicia el component que la posseeix i repeteix la mateixa extracció des del mateix context. Verifica la referència d'imatge i el digest resultants, no l'absència d'error, perquè una capa en memòria cau pot fer que el segon intent recorri molt menys camí que el primer. Conserva al tiquet les transferències que realment s'han produït, ja que són l'únic registre del que el reintent ha provat de debò.

Els passos de construcció i els contenidors en execució tenen els seus propis contextos de xarxa, així que tracta'ls com a preguntes separades quan la mateixa extracció ja funcioni.