Vider le cache DNS Windows avec ipconfig /flushdns

Quand Windows garde une ancienne adresse IP en mémoire, un site, une application métier ou un serveur interne peut rester inaccessible alors que le service fonctionne déjà ailleurs. Dans ce cas, la commande ipconfig /flushdns vide le cache DNS local et force Windows à redemander les bonnes informations au prochain accès.

La commande est rapide, sans risque pour les fichiers, et utile après un changement DNS, une migration de site, un VPN capricieux ou une erreur “site introuvable”. Elle ne remplace pas un diagnostic réseau complet, mais c’est souvent le premier test propre à lancer sur un poste Windows.

La commande à utiliser

Pour vider le cache DNS Windows, ouvrez un terminal et exécutez simplement ipconfig /flushdns. Windows supprime alors les enregistrements DNS conservés localement par le résolveur. Au prochain accès à un domaine, le poste devra interroger à nouveau sa chaîne DNS : cache navigateur, système, routeur éventuel, résolveur configuré et serveur autoritaire.

Dans la plupart des cas, l’invite de commandes ou PowerShell suffit. Le mode administrateur reste préférable dans un environnement d’entreprise, car il évite les restrictions liées aux politiques locales et donne un résultat plus prévisible. Si la commande répond que le cache a été vidé, la purge Windows est faite.

Ne multipliez pas les commandes au hasard. Lancez la purge, testez l’accès concerné sur le domaine exact, puis passez à l’étape suivante seulement si le problème persiste.

Quand vider le cache DNS aide vraiment

La purge est pertinente quand le poste utilise encore une information périmée. C’est fréquent après un changement d’hébergement, une modification de zone DNS, une bascule de messagerie, une entrée interne remplacée ou un changement de VPN. Le symptôme typique : un autre poste accède au service, mais pas celui que vous dépannez.

Elle aide aussi lorsque Windows alterne entre plusieurs réseaux : bureau, Wi-Fi invité, partage de connexion, VPN ou accès distant. Le poste peut garder une réponse locale qui ne correspond plus au réseau actuel. Dans ce scénario, le cache DNS n’est pas la cause profonde, mais il peut prolonger le problème après la correction.

Pour approfondir ce point, consultez changer dns windows 11, qui traite plus précisément de changer les dns sur windows 11 sans perdre la connexion.

La commande ne fait pas de miracle. Si le domaine pointe toujours vers la mauvaise adresse dans la zone DNS, si le résolveur de l’entreprise est indisponible ou si le pare-feu bloque la connexion, vider le cache ne changera rien durablement. C’est un nettoyage local, pas une réparation de l’infrastructure. Dans ce cas, la commande peut même donner une fausse impression de progression, parce qu’elle affiche un succès alors que le poste redemande ensuite la même mauvaise information.

Vérifier le cache avant ou après la purge

La commande ipconfig /displaydns affiche les entrées actuellement conservées par Windows. Elle peut être verbeuse, mais elle aide à confirmer qu’un domaine précis apparaît dans le cache ou que la purge a réellement vidé la liste visible. Pour un dépannage simple, il n’est pas nécessaire de tout lire : cherchez surtout le domaine ou le service concerné.

Après ipconfig /flushdns, relancez l’accès au site ou à l’application, puis observez le comportement. Si l’erreur disparaît, l’ancien cache était probablement en cause.

Si l’erreur revient immédiatement, le poste reçoit encore une mauvaise réponse d’un autre niveau : navigateur, routeur, résolveur DNS, VPN ou configuration serveur.

Isoler un poste local d’un incident réseau

La bonne méthode consiste à comparer avant de modifier. Testez le même domaine sur un autre poste, puis sur un autre réseau si possible. Si un seul ordinateur échoue, le cache local, le navigateur, le VPN ou la configuration du poste deviennent prioritaires. Si tout le monde échoue, l’incident est probablement côté DNS réseau, pare-feu, serveur ou fournisseur.

Cette distinction évite de perdre du temps. Dans une petite équipe, on lance souvent la purge DNS sur tous les postes par réflexe, alors qu’un seul test croisé peut montrer que le problème vient du résolveur d’entreprise. À l’inverse, si un poste isolé reste bloqué après une migration, la purge ciblée règle parfois le cas sans toucher à l’infrastructure. C’est aussi plus propre pour le support : chaque action correspond à une hypothèse, puis à un test visible par l’utilisateur.

Le test le plus lisible pour un utilisateur non spécialiste reste l’accès au service réel : site, intranet, outil métier ou messagerie. Pour un administrateur, un contrôle avec nslookup ou un ping peut compléter le diagnostic, mais ces commandes ne remplacent pas la vérification fonctionnelle. Ce qui compte, c’est que le poste atteigne le bon service, pas seulement qu’une commande réponde.

Ne pas oublier le cache DNS du navigateur

Les navigateurs modernes peuvent garder leurs propres informations de résolution. C’est pratique pour accélérer l’accès aux sites, mais cela peut masquer l’effet de la purge Windows. Si le problème persiste dans un seul navigateur, videz son cache DNS interne, fermez les onglets concernés ou redémarrez le navigateur.

Dans une PME, ce détail évite de conclure trop vite à une panne réseau. Un poste peut avoir un cache Windows propre, mais un navigateur encore bloqué sur une ancienne réponse. Le bon ordre consiste à purger Windows, tester dans un second navigateur, puis seulement ensuite regarder routeur, VPN ou serveur DNS.

Sur un poste partagé ou administré, pensez aussi aux profils utilisateurs. Un navigateur ouvert avec plusieurs profils, extensions ou sessions synchronisées peut conserver un comportement différent d’un autre profil Windows. Le test en navigation privée n’est pas parfait, mais il donne souvent une indication rapide avant de vider plus largement les données du navigateur.

Diagnostic

Deux niveaux de cache à distinguer

La résolution DNS ne dépend pas uniquement de Windows.

Cache Windows

Il est vidé par ipconfig /flushdns et concerne le résolveur DNS du système.

Cache navigateur

Il peut conserver une réponse différente et doit parfois être vidé séparément.

Les erreurs à éviter

La première erreur est d’utiliser la purge DNS comme solution universelle. Si le Wi-Fi est coupé, si le DNS configuré ne répond pas ou si la zone DNS contient une mauvaise valeur, la commande peut donner une impression d’action sans résoudre le sujet. Le diagnostic réseau doit rester factuel.

La deuxième erreur est de confondre cache DNS et cache web. Un site peut encore afficher une ancienne page à cause du cache du navigateur, d’un CDN ou du serveur applicatif, même si le nom de domaine pointe correctement. Dans ce cas, vider le cache DNS ne changera pas le contenu servi.

La troisième erreur est de négliger le délai de propagation après un changement DNS. Certains résolveurs conservent une ancienne réponse jusqu’à expiration du TTL prévu. La purge locale force Windows à redemander une réponse, mais elle ne peut pas accélérer tous les caches situés entre le poste et le serveur autoritaire.

1. Relancer la commande en boucle sans tester le domaine exact.
2. Oublier le VPN alors qu’il change les serveurs DNS utilisés.
3. Ignorer les autres postes et perdre du temps sur un incident global.
4. Confondre DNS et contenu quand le problème vient du cache web.

Notre recommandation

Sur un poste Windows, commencez par ipconfig /flushdns lorsque l’erreur semble locale, récente et liée à un changement d’adresse. Ensuite, testez le domaine dans un autre navigateur, comparez avec un autre poste et vérifiez le VPN si le service est interne. Cette séquence suffit souvent à séparer un simple cache obsolète d’un vrai incident DNS.

Si plusieurs utilisateurs sont touchés, arrêtez de purger poste par poste. La priorité : prouver où la mauvaise réponse apparaît.

En support PME, gardez cette règle : une purge DNS est un geste de remise à zéro locale. Elle est utile, rapide et réversible, mais elle doit toujours être suivie d’un test. Sans ce test, la commande réussie ne prouve pas que le service est de nouveau accessible.

Pour approfondir ce point, consultez dns cloudflare, qui traite plus précisément de dns cloudflare, ce qu’il faut vérifier avant de modifier une zone.