ERR_NAME_NOT_RESOLVED veut dire une seule chose : Chrome n’a pas obtenu d’adresse IP pour le nom du site, donc aucune connexion n’a même été tentée. L’aide Google Chrome le formule ainsi : le nom d’hôte n’existe pas, ou il possède désormais une adresse IP différente.
Points clés
- L’erreur se produit avant toute connexion au serveur : elle concerne la résolution DNS, pas la page.
- Un seul site touché oriente vers l’adresse saisie, le cache local ou le fichier hosts. Tous les sites touchés orientent vers le résolveur DNS ou le réseau.
- Chrome garde un cache DNS interne distinct de celui de Windows : vider l’un ne vide pas l’autre.
- Les deux commandes de référence sont
ipconfig /flushdnsen invite de commandes etClear-DnsClientCacheen PowerShell. - Le paramètre DNS sécurisé de Chrome, avec un fournisseur personnalisé mal renseigné, casse toutes les résolutions du navigateur sans toucher au reste du système.
Ce que fait le navigateur au moment de l’erreur
Quand une adresse est validée dans la barre d’adresse, la première opération n’est pas la connexion : c’est la traduction du nom de domaine en adresse IP. Cette traduction est confiée à un résolveur DNS, celui du routeur, celui du fournisseur d’accès ou un service public. Si le résolveur ne répond pas, répond par une erreur, ou n’est pas joignable, Chrome s’arrête là et affiche le message « Ce site est inaccessible » accompagné du code.
La conséquence pratique est utile : inutile de chercher du côté du serveur web, du certificat ou du cache de la page. Tant que le nom n’est pas résolu, rien de tout cela n’est en jeu.
Le test qui fait gagner du temps
Avant d’ouvrir le moindre réglage, il faut trancher entre un problème isolé et un problème général. Trois observations suffisent :
- Le même site s’ouvre-t-il depuis un autre appareil du même réseau ? Si oui, le problème est local à la machine.
- D’autres sites s’ouvrent-ils sur la machine concernée ? Si non, c’est le résolveur ou le réseau.
- Le site s’ouvre-t-il dans un autre navigateur ? Si oui, c’est le cache DNS interne de Chrome ou son paramètre de DNS sécurisé.
L’aide Google Chromebook propose la même logique pour les messages d’inaccessibilité : vérifier l’adresse saisie, puis tester la page sur un autre ordinateur du réseau, puis vérifier la connexion internet.
Solutions, de la moins risquée à la plus lourde
- Relire l’adresse. Une lettre inversée dans le domaine ou une extension erronée produit exactement cette erreur, puisque le nom demandé n’existe pas. C’est la première vérification recommandée par l’aide Google.
- Vider le cache DNS de Chrome. Ouvrez
chrome://net-internals/#dnset utilisez le bouton de vidage du cache hôte, puischrome://net-internals/#socketspour réinitialiser les pools de sockets. Aucun droit administrateur n’est nécessaire. - Vider le cache DNS de Windows. Dans une invite de commandes lancée en administrateur, exécutez
ipconfig /flushdns. L’équivalent PowerShell estClear-DnsClientCache, documenté par Microsoft comme la commande qui supprime le contenu du cache du client DNS. - Contrôler le DNS sécurisé de Chrome. Dans les paramètres de confidentialité et sécurité, la section Sécurité contient l’option d’utilisation d’un DNS sécurisé. Si un fournisseur personnalisé y a été saisi et que son adresse est fausse ou hors service, toutes les résolutions échouent. Revenez au fournisseur par défaut ou désactivez l’option pour tester.
- Redémarrer le routeur et la machine. Le cache du routeur est un niveau de plus, indépendant de celui du poste. Un cycle d’alimentation d’une trentaine de secondes le purge.
- Changer de serveur DNS. Dans les paramètres réseau de Windows, forcez un résolveur public connu plutôt que celui attribué automatiquement. Si les sites reviennent immédiatement, le résolveur d’origine était en cause.
- Vérifier le fichier hosts. Une entrée résiduelle dans
C:\Windows\System32\drivers\etc\hostspeut détourner un domaine précis vers une adresse morte. Le fichier se lit dans un éditeur de texte lancé en administrateur ; les lignes commençant par un dièse sont des commentaires. - Désactiver temporairement VPN, proxy et filtrage. Un client VPN coupé en cours de route laisse parfois des serveurs DNS injoignables dans la configuration réseau. Un filtre parental ou un antivirus qui intercepte le DNS produit le même effet sur certains domaines.
- Réinitialiser la pile réseau. En dernier recours côté poste,
netsh int ip resetetnetsh winsock reseten invite administrateur, suivis d’un redémarrage. Cette étape efface des réglages réseau personnalisés : elle vient après les autres.
Vérifier si le nom se résout vraiment
Pour savoir si le problème vient du navigateur ou de la résolution elle-même, une commande suffit : nslookup exemple.fr dans une invite de commandes. L’outil, documenté par Microsoft, affiche le serveur interrogé et sa réponse. Deux lectures possibles :
- La commande renvoie une adresse IP mais Chrome échoue encore : le cache interne du navigateur ou son paramètre de DNS sécurisé est en cause.
- La commande échoue aussi : le problème est en amont du navigateur, côté résolveur, réseau ou domaine.
Dans ce second cas, un test croisé avec un résolveur différent, en précisant un serveur à nslookup, permet de distinguer un résolveur en panne d’un domaine réellement inexistant.
Quand cela ne vient pas du poste
Un domaine expiré, une zone DNS mal configurée ou une migration d’hébergement en cours produisent l’erreur pour tout le monde, sans aucun réglage local à corriger. Le signe est net : le site échoue depuis plusieurs réseaux et plusieurs appareils, y compris en données mobiles. Il n’y a alors rien à réparer côté visiteur, il faut attendre la propagation ou contacter l’éditeur du site.
Le cas mobile mérite une mention. Sur Android, un nom d’hôte de DNS privé saisi avec une faute dans les paramètres réseau bloque silencieusement toute résolution sur l’appareil, sur toutes les applications. Le réglage se vérifie dans les paramètres de connexion avancés avant de chercher ailleurs.
Le cas d’un site que vous administrez
Sur un site que vous gérez, WordPress ou autre, l’erreur apparaît typiquement après un changement d’hébergement, un transfert de domaine ou une modification de zone DNS. Le sens de lecture change : ce ne sont pas les paramètres du visiteur qui sont en cause, mais les enregistrements du domaine.
Vérifiez dans cet ordre, depuis l’interface du registrar puis celle de l’hébergeur. L’ouverture du menu de gestion du domaine indique d’abord si le nom est toujours actif et quels serveurs de noms lui sont associés. Le panneau de l’hébergement montre ensuite si la zone contient bien un enregistrement pointant vers le serveur du site. Un essai depuis une connexion mobile, hors de votre box et de son cache, confirme enfin que la correction est bien visible de l’extérieur. La propagation d’une modification de zone n’est pas instantanée, le délai dépend de la durée de vie déclarée sur les enregistrements.
Dernier point souvent oublié côté serveur comme côté poste : un pare-feu ou un filtrage qui bloque le port de résolution empêche toute réponse, avec le même message affiché dans le navigateur. Sur un réseau d’entreprise, la question se pose à l’administrateur avant toute manipulation locale.
Erreurs voisines à ne pas confondre
Plusieurs codes Chrome se ressemblent mais ne pointent pas la même étape. Le code DNS_PROBE_FINISHED_NXDOMAIN indique un domaine explicitement déclaré inexistant par le résolveur, alors que ERR_NAME_NOT_RESOLVED couvre aussi le cas du résolveur muet. ERR_CONNECTION_RESET arrive plus tard, une fois le nom résolu et la connexion ouverte. Quand tous les sites tombent d’un coup, la piste à suivre est plutôt celle du serveur DNS qui ne répond pas. La liste officielle des codes d’erreur de Chrome permet de vérifier à quelle étape correspond un message avant de lancer une manipulation.
Questions fréquentes
Pourquoi le site fonctionne sur le téléphone et pas sur l’ordinateur ?
Parce que les deux appareils n’utilisent ni le même cache DNS ni forcément le même résolveur, surtout si le téléphone est en données mobiles. Cet écart désigne la machine fixe, et en priorité son cache DNS et son fichier hosts.
Faut-il vider le cache de Chrome ou le cache DNS ?
Ce sont deux choses différentes. Le cache des pages et des cookies n’a aucun effet sur la résolution de noms. Le cache DNS interne du navigateur se vide depuis chrome://net-internals/#dns, et celui du système avec ipconfig /flushdns.
L’erreur peut-elle venir du site lui-même ?
Oui. Un domaine non renouvelé ou des enregistrements DNS incorrects provoquent l’erreur pour tous les visiteurs. Le test depuis un réseau totalement différent tranche la question en quelques secondes.
Le DNS sécurisé de Chrome est-il à laisser activé ?
Le réglage existe dans les paramètres de sécurité de Chrome et chiffre les requêtes de résolution. Il reste pertinent avec le fournisseur par défaut. Le risque de blocage vient du mode personnalisé, lorsque l’adresse du fournisseur est mal saisie ou indisponible.
Que faire si l’erreur revient toutes les heures ?
Une erreur intermittente pointe le résolveur plutôt que le poste. Forcer un résolveur public dans les paramètres réseau et observer pendant une journée est le test le plus rapide ; si tout redevient stable, le résolveur attribué par le réseau était bien la cause.
Sources
Photo d’en-tête : Zeitlupe, CC BY-SA 4.0, via Wikimedia Commons. Photo d’illustration d’un routeur grand public, sans lien direct avec un code d’erreur.
Aide Google Chrome, Obtenir de l’aide pour les messages d’erreur courants dans Chrome ·
Aide Google Chromebook, Message d’erreur « Page Web inaccessible » ·
Aide Google Chrome, Gérer votre sécurité dans Chrome ·
Microsoft Learn, ipconfig ·
Microsoft Learn, Clear-DnsClientCache ·
Microsoft Learn, nslookup
Michel, dirigeant d’une PME informatique et formateur, expert en logiciels professionnels tels que CRM et ERP. Sa connaissance approfondie des outils de gestion d’entreprise lui permettant de conseiller et former efficacement d’autres sociétés à leur utilisation.
