La fuente muestra por qué una prueba de velocidad normal no basta para diagnosticar instalaciones lentas de Docker/App Store. El ZimaBoard del usuario tenía una conexión de fibra de 100 Mbps y MySpeed mostraba un rendimiento normal de Internet; sin embargo, las descargas de imágenes de aplicaciones avanzaban a solo unos KB/s y cada instalación tardaba aproximadamente entre 20 y 30 minutos.
IceWhale sospechó del DNS, pero las pruebas no son concluyentes. El usuario desactivó AdGuard Home/Nginx y cambió el DNS a Google 8.8.8.8; las instalaciones seguían siendo lentas. Unos días después, tras actualizar a 1.4.4.4-1, cambiar el DNS a Cloudflare 1.1.1.1 y reiniciar, las instalaciones volvieron a la normalidad. Como se cambiaron varias variables a la vez, la fuente no demuestra que el DNS fuera la única causa ni que por sí solo solucionara el problema.
Una prueba de velocidad rápida no demuestra que las descargas desde registros de Docker sean rápidas
Una prueba de velocidad web se conecta a un servidor de prueba cercano. La instalación de una imagen de Docker puede contactar con resolutores DNS, puntos finales de registros, servicios de autenticación y hosts de CDN ubicados en distintas regiones.
La navegación normal o una prueba de velocidad rápida en la red local pueden coexistir con descargas lentas de imágenes de contenedores.
El DNS era una hipótesis razonable, pero no está demostrada por la fuente
El usuario tenía AdGuard Home, Quad9 y Nginx en el entorno. Giorgio sugirió desactivar las aplicaciones relacionadas con el DNS y probar servicios DNS públicos como 1.1.1.1 o 8.8.8.8.
La primera prueba controlada —desactivar las aplicaciones relacionadas con el DNS y cambiar a 8.8.8.8— no solucionó la instalación lenta. Por lo tanto, no se debe escribir «AdGuard fue la causa» ni «Google DNS lo soluciona».
Compara docker pull en otra máquina
La siguiente pregunta de diagnóstico de IceWhale fue especialmente útil: ejecutar una extracción de Docker para la misma imagen en otra máquina conectada a la misma red.
Si ambos dispositivos son lentos, hay que investigar el ISP, el registro, la CDN y el enrutamiento DNS. Si solo ZimaOS es lento, hay que centrarse en su estado de Docker, de red y del sistema.
Comprueba también el espacio de almacenamiento y el rendimiento de escritura
La instalación de imágenes también escribe y extrae capas. Un disco del sistema casi lleno, un almacenamiento lento o defectuoso, o una E/S simultánea intensa pueden hacer que una instalación parezca limitada por la red aunque la descarga en sí funcione correctamente.
El ZimaOS actual permite mover las imágenes de Docker y AppData a un almacenamiento más grande, además de consultar el uso del almacenamiento de las aplicaciones.
La recuperación descrita en la fuente implicó más que un cambio de DNS
El estado final satisfactorio incluyó:
- ZimaOS actualizado a
1.4.4.4-1; - DNS cambiado a
1.1.1.1; - servidor reiniciado.
Esto confirma que el resultado fue real, pero la causa raíz sigue sin resolverse.
El ZimaOS actual es mucho más reciente que la versión 1.4.4
ZimaOS 1.7 introdujo App Store 2.0 y las versiones posteriores mejoraron el inicio de Docker, la configuración de red, la compatibilidad con YAML y la migración de aplicaciones. Antes de aplicar soluciones alternativas de 2025, reproduce los síntomas actuales de extracción lenta en la versión estable más reciente.
Usa la versión de referencia actual de ZimaOS 1.7.1.
Preguntas frecuentes sobre la instalación lenta de aplicaciones
¿La fuente demostró que la conexión a Internet era lenta?
No. Las pruebas de velocidad normales del servidor eran mucho más rápidas que las descargas de imágenes de App Store a unos pocos KB/s.
¿Cambiar a 8.8.8.8 solucionó el problema?
No. El usuario indicó explícitamente que el problema persistió después de esa prueba.
¿Qué coincidió finalmente con la recuperación?
Una actualización a 1.4.4.4-1, un cambio de DNS a 1.1.1.1 y un reinicio; la fuente no permite aislar cuál de estos cambios fue decisivo.
