DNS_PROBE_FINISHED_NXDOMAIN : signification et solutions

Qu'est-ce que DNS_PROBE_FINISHED_NXDOMAIN ?

DNS_PROBE_FINISHED_NXDOMAIN signifie que Chrome n'a pas pu obtenir d'adresse pour le nom du site, alors que votre serveur DNS a répondu au propre test de Chrome : Chrome en conclut que le domaine n'existe pas. Le plus souvent, c'est une vraie réponse NXDOMAIN (« non-existent domain », domaine inexistant) ; une requête qui échoue pour une autre raison, comme une signature DNSSEC invalide (SERVFAIL), affiche la même page. Chrome l'affiche sous le titre « Ce site est inaccessible ». On la cherche souvent sous le nom DNS_PROBE_NXDOMAIN : Chromium n'a pas de code de ce nom, c'est la même erreur.

Le seul test qui compte : interrogez un DNS public (la Recherche DNS ci-dessous, ou nslookup example.com 1.1.1.1). Si le DNS public trouve le domaine, la cause est de votre côté : faute de frappe, cache obsolète, votre serveur DNS, un service de filtrage ou un VPN. Si le DNS public répond lui aussi NXDOMAIN, le domaine est mal orthographié, expiré ou mal configuré, et seul son propriétaire peut le corriger.

Très souvent, la cause est une faute de frappe ou quelque chose de votre côté, que vous pouvez corriger en quelques minutes ; les étapes ci-dessous vont des vérifications les plus rapides jusqu'au domaine lui-même.

À quoi ressemble cette erreur dans les autres navigateurs

Chaque navigateur affiche cette erreur DNS différemment, mais la cause sous-jacente est toujours la même : le domaine n'a pas pu être résolu.

Les navigateurs basés sur Chromium (Chrome, Edge, Brave, Opera) affichent tous le même code DNS_PROBE_FINISHED_NXDOMAIN. Firefox et Safari montrent un message plus convivial, mais le problème sous-jacent est identique.

NXDOMAIN et les autres erreurs DNS_PROBE de Chrome

Quand une page ne se charge pas, Chrome lance une rapide vérification DNS et nomme le résultat avec un code DNS_PROBE. Un seul d'entre eux signifie que le nom n'existe pas :

L'erreur ERR_NAME_NOT_RESOLVED de Chrome correspond au même échec (« aucune adresse pour ce nom »), affiché quand Chrome ne lance pas sa vérification ou que celle-ci n'est pas concluante : voir ERR_NAME_NOT_RESOLVED.

Causes courantes de DNS_PROBE_FINISHED_NXDOMAIN

Les causes se répartissent entre votre côté (la plupart) et celui du domaine.

• Faute de frappe dans l'URL — Une cause très fréquente. Un seul caractère erroné (par ex. gogle.com au lieu de google.com) déclenche NXDOMAIN car le domaine mal orthographié n'existe pas dans le DNS.
• Un « n'existe pas » gardé en cache — votre ordinateur ou votre serveur DNS a mémorisé une ancienne réponse NXDOMAIN, par exemple d'avant la mise en place du domaine, et la répète jusqu'à son expiration.
• Cache DNS interne de Chrome — Chrome gère son propre cache DNS, séparé de celui de votre système. Même après avoir vidé le cache système, Chrome peut encore utiliser une entrée interne obsolète.
• Un service DNS filtrant — Quad9 répond NXDOMAIN pour les domaines qu'il bloque : un site qui fonctionne semble alors ne pas exister. (Pi-hole, AdGuard et Cloudflare for Families répondent 0.0.0.0 par défaut, ce qui affiche plutôt une erreur de connexion.)
• Domaine non enregistré ou expiré — Le propriétaire du site a oublié de renouveler le domaine, ou celui-ci n'a jamais été enregistré.
• Un domaine tout neuf — un résolveur qui a interrogé le nom avant la mise en place du domaine garde la réponse « n'existe pas » pendant la durée de cache négatif de la zone : 15 minutes pour .com et .net.
• Un nom local absent de votre fichier hosts — les noms de développement comme myapp.test n'existent que là où vous les définissez (une mauvaise entrée hosts provoque une erreur de connexion, pas NXDOMAIN).
• VPN ou pare-feu bloquant l'accès — Un VPN, un proxy ou un pare-feu intercepte les requêtes DNS et bloque ou redirige le domaine.
• Problème avec le serveur DNS du FAI — Le serveur DNS de votre fournisseur d'accès renvoie NXDOMAIN de manière incorrecte, ou il n'a pas encore reçu les enregistrements DNS du domaine.

Solution 1 : vérifier l'orthographe du nom de domaine

Vérifiez attentivement l'URL dans votre barre d'adresse : un seul caractère erroné suffit.

Recherchez les fautes de frappe courantes : lettres manquantes (goole.com), lettres en trop (googgle.com), mauvaise extension (.con au lieu de .com), ou caractères confondus (goog1e.com avec le chiffre 1 au lieu de la lettre l).

Si quelqu'un vous a envoyé le lien, essayez plutôt de rechercher le site sur Google au lieu de cliquer directement sur le lien. Si le domaine n'existe vraiment pas, aucun résultat de recherche n'apparaîtra.

Solution 2 : vider le cache DNS

Si le domaine est correctement orthographié, l'étape suivante consiste à vider le cache DNS de votre système d'exploitation. Cela supprime toutes les entrées DNS stockées et force de nouvelles résolutions.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome OS
chrome://net-internals/#dns → Clear host cache

Après avoir vidé le cache, essayez de recharger le site. Si les enregistrements DNS du domaine ont été récemment mis à jour, le vidage du cache permet à votre système de récupérer les nouveaux enregistrements.

Les commandes pour chaque système, routeurs compris : comment vider le cache DNS.

Solution 3 : purger le cache DNS interne de Chrome

Chrome gère son propre cache DNS, complètement séparé du cache de votre système. Vider le cache système seul ne suffit pas — vous devez également purger le cache interne de Chrome.

• Ouvrez Chrome et tapez chrome://net-internals/#dns dans la barre d'adresse
• Cliquez sur « Clear host cache » pour purger toutes les entrées DNS mises en cache par Chrome
• Puis allez à chrome://net-internals/#sockets et cliquez sur « Flush socket pools » pour réinitialiser les connexions ouvertes
• Essayez de recharger le site — Chrome effectuera désormais une résolution DNS entièrement nouvelle

Solution 4 : passer à un serveur DNS public

Le serveur DNS de votre FAI peut renvoyer des réponses NXDOMAIN incorrectes, ou il n'a pas encore les enregistrements du domaine. Passer à un serveur DNS public fiable résout souvent ce problème.

Changer le DNS sur Windows

• Ouvrez Paramètres → Réseau et Internet → Wi-Fi → Gérer les réseaux connus → votre réseau (en filaire : Ethernet → votre réseau)
• Repérez Attribution du serveur DNS sur cette page
• Cliquez sur Modifier à côté de Attribution du serveur DNS → passez en Manuel
• Activez IPv4 et définissez le DNS préféré sur 1.1.1.1, l'alternatif sur 1.0.0.1
• Cliquez sur Enregistrer et testez le site à nouveau

Changer le DNS sur macOS

• Ouvrez Réglages Système → Réseau → Wi-Fi → Détails
• Cliquez sur DNS dans la barre latérale
• Supprimez les entrées existantes et ajoutez 1.1.1.1 et 1.0.0.1
• Cliquez sur OK

Solution 5 : vérifier le fichier hosts

Votre fichier hosts associe des noms à des adresses avant toute requête DNS. Une mauvaise entrée (127.0.0.1 example.com) donne une adresse au nom : vous obtenez une connexion refusée ou un mauvais site, pas NXDOMAIN. Supprimez quand même ces lignes, car des malwares et d'anciens bloqueurs de publicités en ajoutent.

Le fichier hosts provoque bien NXDOMAIN dans le cas inverse : un nom de développement local (myapp.test, api.local) que vous n'avez jamais ajouté. Le DNS public ne le connaît pas, donc la résolution échoue.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines like:
# 127.0.0.1  example.com    ← This blocks the domain!
# 0.0.0.0    example.com    ← This also blocks it!

# If you find the domain listed, delete that line and save.

Après modification, enregistrez le fichier et videz le cache DNS (Solution 2).

Solution 6 : vérifier le réglage DNS sécurisé de Chrome

Chrome peut envoyer ses requêtes DNS via HTTPS à un fournisseur choisi dans Chrome au lieu d'utiliser le DNS de votre système. Si ce fournisseur filtre (DNS familial ou de sécurité), Chrome obtient « ce domaine n'existe pas » pour des sites que les autres navigateurs chargent sans problème. (Si le fournisseur est injoignable, Chrome affiche plutôt DNS_PROBE_FINISHED_BAD_SECURE_CONFIG.)

• Ouvrez chrome://settings/security (Paramètres → Confidentialité et sécurité → Sécurité)
• Repérez « Utiliser un DNS sécurisé » et notez le fournisseur choisi sous « Sélectionner un fournisseur DNS »
• Réglez « Sélectionner un fournisseur DNS » sur « Valeur par défaut de l'OS (si disponible) », ou sur Google ou Cloudflare, puis rechargez le site
• Edge : edge://settings/privacy → « Security » → « Use secure DNS » (libellés de la version anglaise)

Si changer de fournisseur règle le problème, le précédent bloquait ce domaine ou n'arrivait pas à le résoudre.

Solution 7 : désactiver temporairement le VPN ou l'antivirus

Les VPN envoient vos requêtes DNS à leurs propres serveurs, et les logiciels de sécurité, Pi-hole, les routeurs et les services DNS familiaux filtrent les noms qu'ils jugent risqués. Quad9 répond NXDOMAIN pour un domaine bloqué : le site semble alors ne pas exister ; la plupart des autres filtres répondent 0.0.0.0, ce qui affiche plutôt une erreur de connexion.

Désactivez le VPN ou le filtre et rechargez la page. Pour confirmer un blocage par Quad9, utilisez dig : selon la documentation de Quad9, un domaine qu'il bloque renvoie NXDOMAIN avec AUTHORITY: 0 (et sans le drapeau ra), alors qu'un domaine qui n'existe vraiment pas revient avec l'enregistrement SOA de la zone (AUTHORITY: 1). Le domaine de test de Quad9 est isitblocked.org :

dig isitblocked.org @9.9.9.9

# ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
# ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0   ← blocked by Quad9

# A name that really doesn't exist:
# ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1   ← the zone's SOA comes back

Solution 8 : vérifier l'état d'enregistrement du domaine

Si aucune des solutions précédentes ne fonctionne, le domaine lui-même est peut-être réellement non enregistré ou expiré. C'est fréquent avec les nouveaux sites, les domaines récemment changés, ou les domaines que le propriétaire a oublié de renouveler.

Pour vérifier l'état du domaine :

• Utilisez le WHOIS de DNS Robot sur /whois-lookup — saisissez le domaine et vérifiez les dates d'enregistrement et d'expiration
• Utilisez la Recherche DNS de DNS Robot sur /dns-lookup — si aucun enregistrement A, AAAA ou NS n'existe, le domaine n'a pas de configuration DNS
• Nouveau domaine ou nouvel enregistrement ? Un résolveur qui a interrogé le nom avant qu'il existe conserve la réponse « n'existe pas » pendant la durée de cache négatif fixée dans l'enregistrement SOA de la zone (RFC 2308) : 15 minutes pour .com et .net, en général moins d'une heure ailleurs. Le DNS public peut déjà voir le domaine alors que le résolveur de votre FAI renvoie encore NXDOMAIN
• Enregistré mais non résolu ? Si le WHOIS affiche le domaine mais qu'il n'a aucun serveur de noms, ou que son statut est clientHold ou serverHold (après une expiration ou un e-mail du titulaire non vérifié), le TLD répond NXDOMAIN : corrigez cela chez le registrar. Des serveurs de noms qui n'ont tout simplement pas la zone donnent SERVFAIL ou REFUSED à la place

NXDOMAIN sur des noms de développement locaux

Si le nom qui échoue est un nom que vous avez inventé pour le développement (myapp.test, api.local, un nom de service Docker), le DNS public ne l'a jamais vu : NXDOMAIN est donc la bonne réponse. Faites plutôt résoudre ce nom sur votre machine :

• Utilisez localhost — http://localhost:8000 et http://127.0.0.1:8000 se résolvent toujours ; la plupart des serveurs de développement (Django, Rails, Vite, Next.js) affichent l'une de ces adresses
• Ajoutez le nom à votre fichier hosts — 127.0.0.1 myapp.test, puis videz le cache DNS
• Noms Docker — un nom de service comme db ne se résout qu'à l'intérieur du réseau Docker ; depuis votre ordinateur, utilisez localhost et le port publié
• Noms en .local — ils utilisent le DNS multicast (mDNS), intégré à macOS, iOS et Windows 10 et 11 ; sous Linux, activez Avahi ou le mDNS de systemd-resolved

Corriger DNS_PROBE_FINISHED_NXDOMAIN sur Android

L'erreur NXDOMAIN apparaît sur Chrome pour Android avec le même code d'erreur. Voici comment la corriger.

• Vider le cache de Chrome : Ouvrez Chrome → Paramètres → Confidentialité et sécurité → Supprimer les données de navigation → cochez Images et fichiers en cache → Supprimer les données
• Vérifier le DNS privé : Paramètres → Réseau et Internet → DNS privé (à quoi il sert). S'il pointe vers un service de filtrage, choisissez « Automatique » ou dns.google
• Activer/désactiver le mode avion : Activez le mode avion pendant 10 secondes, puis désactivez-le — cela force une nouvelle connexion réseau et une nouvelle résolution DNS
• Mettre Chrome à jour : Ouvrez le Play Store → cherchez Chrome → appuyez sur Mettre à jour si disponible
• Redémarrez votre appareil si aucune des solutions ci-dessus ne fonctionne

Corriger DNS_PROBE_FINISHED_NXDOMAIN sur iPhone / iPad

Sur iOS, Safari affiche « Safari ne parvient pas à trouver le serveur » au lieu du code d'erreur Chrome. Si vous utilisez Chrome sur iOS, vous verrez le message DNS_PROBE_FINISHED_NXDOMAIN. Voici comment corriger cette erreur.

• Changer le DNS : Allez dans Réglages → Wi-Fi → appuyez sur l'icône (i) à côté de votre réseau → Configurer le DNS → Manuel → ajoutez 1.1.1.1 et 1.0.0.1
• Vider le cache de Safari : Réglages → Apps → Safari → Effacer historique, données de site
• Vider le cache de Chrome : dans Chrome, touchez ⋯ (Plus) → Supprimer les données de navigation
• Activer/désactiver le mode avion : Activez-le pendant 10 secondes, puis désactivez-le pour réinitialiser la connexion réseau
• Redémarrez votre appareil pour effacer tout l'état DNS temporaire

Comment vérifier que la correction a fonctionné

Après avoir appliqué une solution, vérifiez que la résolution DNS fonctionne pour le domaine concerné.

# Test DNS resolution directly
nslookup example.com

# Test with a specific DNS server
nslookup example.com 1.1.1.1

# Detailed test (Mac/Linux)
dig example.com

# status: NXDOMAIN from your own resolver? Confirm with a public one
# before concluding the domain doesn't exist:
dig example.com @1.1.1.1

Si nslookup renvoie une adresse IP, le DNS fonctionne et le site devrait se charger. S'il renvoie toujours « Non-existent domain », soit le domaine n'est véritablement pas enregistré, soit vous devez essayer un autre serveur DNS.

Vous pouvez également utiliser l'outil de Recherche DNS de DNS Robot pour vérifier si le domaine est résolu depuis plusieurs serveurs à travers le monde — cela confirme si le problème est local à votre appareil ou s'il s'agit d'un problème DNS global.