Por qué docker pull ignora el proxy de tu contenedor
Configura el componente de Docker que realmente descarga las imágenes en vez de esperar que las variables del contenedor controlen el daemon.
Si falla docker pull, configura el daemon de Docker o Docker Desktop. La imagen se descarga antes de que el contenedor de la aplicación pueda leer sus variables de proxy.
Docker Engine nativo
Combina esta sección con la configuración de proxy existente del daemon, sustituyendo el endpoint de documentación y conservando los ajustes ajenos. Para pruebas con imágenes públicas donde se permitan proxies públicos, la lista de proxies HTTP ofrece candidatos:
{
"proxies": {
"http-proxy": "http://203.0.113.10:8080",
"https-proxy": "http://203.0.113.10:8080",
"no-proxy": "localhost,127.0.0.1,registry.example.internal"
}
}Las claves del daemon con guiones difieren de las claves camelCase de ~/.docker/config.json del cliente Docker. La sección proxy del cliente aporta variables de entorno a contenedores nuevos y builds; no configura las descargas del daemon ni el entorno de contenedores existentes.
Aplica el reinicio del daemon documentado para la instalación y planifica su efecto sobre las cargas actuales. El daemon también puede recibir variables de proxy en su entorno de arranque; un export posterior en una terminal no actualiza un servicio en ejecución.
Docker Desktop
Usa la configuración de proxy de Desktop. Docker documenta que Desktop ignora las entradas de proxy en daemon.json, por lo que cambiar repetidamente el ejemplo de Engine nativo no configura la ruta de este producto.
Vuelve a descargar la imagen después de actualizar el componente real. Identifica si falló el acceso al registro, la autenticación, las redirecciones o la descarga de capas. Una petición HTTP correcta dentro de un contenedor existente solo comprueba la ruta de esa aplicación. No incluyas credenciales de proxy en capturas compartidas ni archivos confirmados; la configuración del daemon y el entorno del contenedor no son almacenes de secretos.