La source montre pourquoi un test de débit classique ne suffit pas pour diagnostiquer la lenteur des installations Docker/App Store. Le ZimaBoard de l’utilisateur disposait d’une connexion fibre à 100 Mbit/s et MySpeed affichait un débit Internet normal, tandis que les téléchargements d’images d’applications stagnaient à seulement quelques Ko/s et que chaque installation prenait environ 20 à 30 minutes.
IceWhale soupçonnait le DNS, mais les éléments disponibles sont mitigés. L’utilisateur a désactivé AdGuard Home/Nginx et remplacé le DNS par celui de Google, 8.8.8.8 ; les installations restaient lentes. Quelques jours plus tard, après la mise à jour vers 1.4.4.4-1, le remplacement du DNS par celui de Cloudflare, 1.1.1.1, et un redémarrage, les installations ont retrouvé une vitesse normale. Comme plusieurs variables ont changé simultanément, la source ne prouve pas que le DNS, à lui seul, ait causé ou résolu le problème.
Un test de débit rapide ne prouve pas que les téléchargements depuis un registre Docker sont rapides
Un test de débit effectué sur le Web contacte un serveur de test situé à proximité. L’installation d’une image Docker peut contacter des résolveurs DNS, des points d’accès de registre, des services d’authentification et des hôtes CDN situés dans différentes régions.
Une navigation normale ou un test de débit local rapide peuvent donc coexister avec des téléchargements d’images de conteneurs lents.
Le DNS était une hypothèse raisonnable, mais elle n’est pas confirmée par la source
L’utilisateur avait AdGuard Home, Quad9 et Nginx dans son environnement. Giorgio a suggéré de désactiver les applications liées au DNS et d’essayer un DNS public comme 1.1.1.1 ou 8.8.8.8.
Le premier test contrôlé — désactiver les applications liées au DNS et passer à 8.8.8.8 — n’a pas résolu la lenteur de l’installation. N’écrivez donc pas qu’« AdGuard en était la cause » ou que « le DNS de Google résout le problème ».
Comparez docker pull sur une autre machine
La question de diagnostic suivante d’IceWhale était particulièrement utile : effectuer un téléchargement Docker de la même image sur une autre machine connectée au même réseau.
Si les deux appareils sont lents, recherchez un problème lié au routage du FAI, du registre, du CDN ou du DNS. Si seul ZimaOS est lent, concentrez-vous sur son état Docker, réseau ou système.
Vérifiez également l’espace de stockage et les performances d’écriture
L’installation d’une image écrit et extrait également des couches. Un disque système presque plein, un stockage lent ou défaillant, ou d’importantes opérations d’E/S simultanées peuvent donner l’impression que l’installation est limitée par le réseau, même si le téléchargement lui-même fonctionne correctement.
Les versions actuelles de ZimaOS permettent de déplacer les images Docker et les données d’application vers un stockage plus volumineux, ainsi que de consulter l’espace utilisé par les applications.
La récupération décrite dans la source a modifié davantage que le DNS
L’état final fonctionnel comprenait :
- ZimaOS mis à jour vers
1.4.4.4-1; - DNS remplacé par
1.1.1.1; - serveur redémarré.
Le résultat est donc réel, mais la cause première reste indéterminée.
La version actuelle de ZimaOS est bien plus récente que la version 1.4.4
ZimaOS 1.7 a introduit l’App Store 2.0, et les versions ultérieures ont amélioré le démarrage de Docker, la configuration réseau, la compatibilité YAML et la migration des applications. Reproduisez les symptômes actuels de téléchargement lent sur la dernière version stable avant d’appliquer des solutions de contournement datant de 2025.
Utilisez la base actuelle de ZimaOS 1.7.1.
FAQ sur les installations d’applications lentes
La source a-t-elle prouvé que la connexion Internet était lente ?
Non. Les tests de débit normaux du serveur étaient bien plus rapides que les téléchargements d’images de l’App Store, limités à quelques Ko/s.
Le passage à 8.8.8.8 a-t-il résolu le problème ?
Non. L’utilisateur a explicitement indiqué que le problème persistait après ce test.
Quels changements ont finalement coïncidé avec le rétablissement du service ?
Une mise à jour vers 1.4.4.4-1, le remplacement du DNS par 1.1.1.1 et un redémarrage ; la source ne permet pas d’isoler le changement décisif.
