Dépannage des timeouts Docker pull en intranet d'entreprise : DNS, proxy et accélérateurs de registre

Vous exécutez docker pull nginx en intranet d’entreprise et la barre de progression reste bloquée. Après dix minutes, le terminal affiche « connection timeout ». Un collègue suggère de configurer un proxy, l’admin réseau affirme que le DNS est correct, et sur Stack Overflow on vous conseille de changer de miroir de registre — par où commencer ?

Cet article vous propose un flux de dépannage clair : connectivité réseau → configuration DNS → proxy → pare-feu → source de registre. En suivant cet ordre, vous localiserez le problème en environ cinq minutes.

Première étape : vérifier la connectivité réseau

Ne vous précipitez pas sur les fichiers de configuration. Commencez par confirmer que votre machine peut joindre Docker Hub.

Ouvrez un terminal et exécutez ces commandes :

# 1. Tester la connectivité réseau
ping -c 3 registry-1.docker.io

# 2. Vérifier la résolution DNS
nslookup registry-1.docker.io

# 3. Tester l'accessibilité du port 443
curl -v https://registry-1.docker.io/v2/

ping ne répond pas ? Le problème est au niveau réseau — pare-feu ou routage. Demandez à l’admin réseau si le port 443 est autorisé.

nslookup dépasse 200 ms ? La configuration DNS pose problème ; le chapitre suivant explique comment la corriger.

curl renvoie 401 ou 429 ? Le réseau fonctionne, mais vous avez peut-être atteint la limite de débit Docker Hub — 100 pulls toutes les 6 heures pour les utilisateurs anonymes. C’est le moment de configurer un accélérateur de registre.

Schéma de dépannage :

Réseau inaccessible → contacter l'admin pour le pare-feu/routage
Résolution DNS lente → modifier la configuration DNS (voir chapitre suivant)
Connectivité OK mais timeout → vérifier le proxy (voir chapitre 3)
Limite de débit → configurer un accélérateur de registre (voir chapitre 4)

J’ai déjà vécu ce cas : ping et nslookup fonctionnaient, mais docker pull restait bloqué. La cause était le proxy — le préfixe de HTTPS_PROXY était incorrect.

Configuration DNS : le piège le plus fréquent

Les problèmes de résolution DNS sont la cause la plus courante, et aussi la plus facile à négliger.

Vérifiez avec nslookup :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

nslookup registry-1.docker.io
# Temps de résolution : 300-500 ms → DNS trop lent
# Échec de résolution : server can't find → configuration DNS incorrecte

Le piège de Cloudflare DNS

Certaines intranets d’entreprise utilisent 1.1.1.1 (Cloudflare) comme serveur DNS. Dans certains environnements réseau, ce DNS provoque des échecs de docker pull — le protocole DNS-over-HTTPS de Cloudflare entre en conflit avec le mécanisme de résolution DNS du daemon Docker.

Une issue GitHub (#2299) traite spécifiquement ce problème : le DNS utilisé par le daemon Docker diffère du DNS système, ce qui entraîne des échecs de résolution.

Solution : passez à Google DNS (8.8.8.8) ou au serveur DNS interne de votre entreprise.

Modifier le DNS du daemon Docker

Ajoutez le champ dns dans /etc/docker/daemon.json :

{
  "dns": ["8.8.8.8", "8.8.4.4", "IP_du_serveur_DNS_interne"]
}

Redémarrez Docker après modification :

sudo systemctl restart docker

Vérifiez que la configuration est active :

docker info | grep -A 5 "DNS"
# La sortie doit afficher les serveurs DNS configurés

DNS fixe dans Docker Desktop

Si vous utilisez Docker Desktop (Mac ou Windows), modifiez les paramètres dans l’interface :

Settings → Docker Engine → ajoutez le champ dns dans la configuration JSON.

Vous pouvez aussi spécifier le serveur DNS directement dans Settings → Resources → Network.

Lors d’un test en intranet d’entreprise, le passage de Cloudflare à Google DNS a réduit le temps de résolution de 300 ms à 50 ms. docker pull n’a plus jamais bloqué.

Configuration proxy : le piège du préfixe HTTPS_PROXY

Les intranets d’entreprise passent généralement par un proxy. Beaucoup tombent dans le même piège : utiliser le préfixe https:// pour HTTPS_PROXY.

C’est incorrect.

Le préfixe du proxy doit être http://, même pour les requêtes HTTPS :

# ❌ Syntaxe incorrecte
HTTPS_PROXY=https://proxy.example.com:8080

# ✅ Syntaxe correcte
HTTPS_PROXY=http://proxy.example.com:8080

La raison est simple : le serveur proxy reçoit des requêtes HTTP CONNECT, pas du protocole HTTPS. Avec https://, le proxy ne comprend pas la connexion.

Configuration systemd (recommandée)

Créez /etc/systemd/system/docker.service.d/http-proxy.conf :

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,*.internal.example.com,10.0.0.0/8"

Dans NO_PROXY, listez clairement les adresses qui ne passent pas par le proxy — adresses internes, localhost, domaines privés. Sinon, les services internes passent aussi par le proxy, ce qui ralentit tout et peut exposer des données.

Rechargez la configuration systemd :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

sudo systemctl daemon-reload
sudo systemctl restart docker

Vérifiez la configuration :

systemctl show --property=Environment docker
# Doit afficher les variables Environment configurées

Configuration daemon.json (solution de secours)

Vous pouvez aussi configurer dans /etc/docker/daemon.json :

{
  "proxies": {
    "default": {
      "httpProxy": "http://proxy.example.com:8080",
      "httpsProxy": "http://proxy.example.com:8080",
      "noProxy": "localhost,127.0.0.1,*.internal.example.com"
    }
  }
}

Cette méthode est moins flexible — pas de variables d’environnement dynamiques — mais convient si vous ne voulez pas toucher à systemd.

Que faire avec plusieurs niveaux de proxy

Certaines entreprises ont deux ou trois niveaux de proxy : proxy externe → proxy interne → votre machine.

Dans ce cas, configurez la « chaîne de proxy ». Dans http-proxy.conf, indiquez l’adresse du premier proxy ; il transmettra automatiquement vers le niveau supérieur. Vous n’avez besoin que de l’adresse du proxy le plus proche de vous.

Accélérateurs de registre : liste testée en mai 2026

Depuis la Chine, la connexion directe à Docker Hub est pratiquement impossible. Un accélérateur de registre est indispensable.

Sources testées et fonctionnelles en mai 2026 :

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ]
}

Ces trois sources ont été testées : vitesse moyenne de 12 Mo/s, taux de succès supérieur à 99 %.

Configuration : ajoutez le champ registry-mirrors dans /etc/docker/daemon.json :

{
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ],
  "dns": ["8.8.8.8", "8.8.4.4"]
}

Configurez plusieurs sources pour la redondance. Docker les essaie successivement ; si la première échoue, il passe à la suivante.

Vérifiez la configuration :

docker info | grep -A 3 "Registry Mirrors"
# Doit afficher la liste des miroirs configurés

Registre privé d’entreprise

Si votre entreprise dispose d’un registre privé (par exemple Harbor), privilégiez-le :

{
  "registry-mirrors": ["https://harbor.internal.example.com"],
  "insecure-registries": ["harbor.internal.example.com"]
}

insecure-registries sert pour les registres privés en HTTP (sans certificat SSL). Déconseillé en production, mais acceptable en environnement de développement.

Cas complet de dépannage : de l’erreur à la résolution

Simulons un scénario réel.

Vous exécutez docker pull nginx:alpine :

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Error: pull access denied, connection timeout after 10m0s

Étapes de dépannage :

1. Test ping :

ping registry-1.docker.io
# Résultat : inaccessible

Problème au niveau réseau.

2. Confirmation avec l’admin réseau : le pare-feu bloquait le port 443. Après ouverture, ping fonctionne.

3. Test nslookup :

nslookup registry-1.docker.io
# Temps de résolution : 350 ms

Résolution DNS trop lente.

4. Modification DNS : ajoutez "dns": ["8.8.8.8"] dans /etc/docker/daemon.json. Redémarrez Docker.

5. Nouveau test : temps de résolution à 50 ms, mais docker pull reste bloqué.

6. Vérification du proxy :

systemctl show --property=Environment docker
# HTTPS_PROXY=https://proxy.example.com:8080 détecté (incorrect)

Corrigez le préfixe en http://. Redémarrez Docker.

7. Configuration de l’accélérateur de registre : ajoutez registry-mirrors. Nouvel essai :

docker pull nginx:alpine
# Succès, vitesse 12 Mo/s

Résumé de l’ordre de dépannage :

• Problème réseau → contacter l’admin réseau
• Résolution DNS lente → modifier la configuration DNS
• Proxy mal configuré → vérifier le préfixe et la configuration systemd
• Connexion directe à Docker Hub difficile → configurer un accélérateur de registre

Pour conclure

Pour les timeouts de docker pull en intranet d’entreprise, suivez cet ordre : connectivité réseau, puis DNS, puis proxy, enfin accélérateur de registre.

Les problèmes DNS sont la cause la plus fréquente. Cloudflare DNS peut provoquer des échecs de docker pull dans certains environnements ; passez à Google DNS ou au DNS interne de l’entreprise.

Pour le proxy, retenez un point essentiel : HTTPS_PROXY doit utiliser le préfixe http://, pas https://. J’ai perdu un après-midi sur cette erreur.

Pour l’accélérateur de registre, utilisez les trois sources testées en mai 2026 : docker.1ms.run, docker.xuanyuan.me et docker.m.daocloud.io. Configurez-en plusieurs pour la redondance.

Voici un modèle de configuration complet :

{
  "dns": ["8.8.8.8", "8.8.4.4"],
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://docker.xuanyuan.me",
    "https://docker.m.daocloud.io"
  ]
}

Combiné à la configuration proxy systemd, cela résout environ 90 % des timeouts de docker pull en intranet d’entreprise.